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effected, at least partially, through a computerized system 
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purchasing transactions and storing the transaction data in 
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WO 01/75745 PCT/USOl/10798 
SYSTEM AND METHOD FOR MANAGING PURCHASING CONTRACTS 



BACKGROUND OF THE INVENTION 

The present invention relates generally to a system and method for managing infoirmation 
or data and, alternatively, such a system and method for generating, monitoring, managing and/or 
otherwise maintaining certain aspects of a contract relationship. The present invention is 
particularly adapted to a system and method for generating, managing and/or monitoring a 
purchasing contract relationship such as a bulk purchasing contract between a common carrier 
entity such an airline operator and a customer entity. Further, the inventive system and method 
are particularly adapted for implementation via or on an electronic environment such as any 
client-server system including those incorporating temdnals, personal computers, digital personal 
assistants and the like, the Intemet, or an Intranet. 

Businesses reward customer volume buying with discounts or deals. Contracted deals 
comprise one or more purchasing requirements, or terms, for volume buying. Contract terms 
may include commitments for the purchase of a specified number of units, or the expenditure of 
a monetary amount, or that a designated share of a company's purchasing be dedicated to a 
specified suppher. Each party seeks financial gain fi:om the deal. The supplier seeks to increase 
volume and to generate higher unit sales and profits. The customer seeks to lower costs through 
discounts. 

In a global business setting, suppliers often form alUances to provide services to 
customers worldwide. AlUance deals involve contract terms firom two or more suppliers. Both 
suppHers and customers benefit firom alliance deals. A supplier can extend its services into 
markets which it would not ordinarily serve but which may be served by an alliance partner. 
Customers, on the other hand, are able to consolidate their global purchasing volume to benefit 
firom worldwide discounts with a reduced number of suppliers. 

Many of such contractual relationships necessarily require management of certain aspects 
of contracts in an electronic or computerized environment. Although the utilization of electronic 



1 



wo 01/75745 



PCT/USOl/10798 



or computer networks facilitate the various contract managemrat processes, it can present certain 
challenges as well. For example, more than one distributor will probably be authorized to sell 
products to a customer. Accordingly, a supplier will collect contract-related information from 
more than one source and will often receive the information in raw or non-standardized form. 
In addition, suppliers and distributors are often located in different parts of the world and may 
use different systems which produce incompatible electronic transactions. 

SUMMARY OF THE INVENTION 

It is, therefore, one of several objects of the present invention to provide a system and 
method for maintaining a contract including the tasks of generating, managing, and monitoring 
certain aspects of the contract (sometimes collectively referred to herein as "contract 
management"). More particularly, it is an object of the invention to provide such a system or 
method for managing a contract between one or more supplier entities and one or more customer 
entities. In this regard, a preferred system or method is one that is particularly adapted to a 
computerized or electronic environment and which allows for the collection, manipulation or 
management of information in a maimer that facilitates the various contract management tasks. 
Various aspects of the system or method may be employed by the supplier entity (including a 
distributor), a customer entity or a third-party agent or facilitator. 

In one aspect of tihe invention, there is provided a system and method of managing 
purchasing contracts between supplier entities and customer entities for the purchase of products. 
The method includes the step of generating at least one purchasing contract between at least one 
supplier entity (e.g., a product originator such as an airline company or a distributor such as a 
travel agency) and at least one customer entity. The purchasing contract generated would be one 
that governs, or is applicable to, one or more contracted purchasing transactions effected, at least 
partially, through a computerized system (e.g., the purchase of a ticket from an origination city 
to a destination city). The generating step includes identifying one or more contract terms, 
wherein each contract term has one or more term attributes, and storing a term data set of the 
term attributes associated with each contract term in one or more computer databases. For 
example, contract term attributes stored as term data set in an airline industry application 
described herein include contract and term unique identifier. ' The method also involves 
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collecting transaction data relating to one or more purchasing transactions and storing the 
transaction data in one or more computer databases. For example, transaction data collected in 
an airline industry application described herein include origin and destination, supplier and 
customer information. 

Preferably, a computer program is executed to identify one or more of the purchasing 
transactions as a contracted transaction (i.e. , applicable to a specific contract) by selecting at least 
a portion of the transaction data received for a purchasing transaction and comparing the selected 
portion with the term attributes for a contract term. In this way, the transaction may be identified 
(i.e., marked) as a contracted transaction if the selected portion is identified with one or more of 
the term attributes. For example, in an ^phcation for the airlines industry, ticketing transactions 
are identified to a contract by examining the departure date, the customer identity, or ticket 
company or agency, among other attributes. 

The method finther includes the step of generating a collection of contract transaction 
data sets by associating at least a portion of the transaction data of each identified contracted 
transaction with at least a portion of each term data set with which the transaction is identified. 
For example, a unique contract term identifier or ED, a unique contract identifier or ID, and/or 
term requirement or discoimt designation may be associated with each identified transaction data 
set. Such a contract-specific and preferably computer-accessible collection of data sets may be 
utilized to measure contract term performance and also to generate reports and summaries for the 
contract. 

The inventive system and method allow a supplier to manage a contract whereby the 
customer may transact with a plurality of distributors and/or the suppUer. It should be noted that 
from hereon the term "supplier" or "supplier entity" may refer to a product originator (e.g., an 
airline) as well as a distributor (e.g., a travel agency). The present invention also facilitates the 
management of contracts wherein the product generator and distributors are located in different 
parts of the world and/or use systems which produce incompatible electronic transactions or 
transaction data. In this respect, one aspect of the invention is the creation of a standardized data 
format and also a contract-specific computer accessible data set for a contract or contract term. 
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The present inventive system and method also provide a means for a sxippUer entity to 
identify transactions to a contract or a contract terai. Further, such a means is provided that is 
implemented through computerized systems and computer programs operable therewith. In this 
way, an automated method of contract management is provided. 

In a system andmethod formeasuring contract performance, i.e., for bulk purchases over 
a period of time, the present invention provides a system and method, which converts 
information or data, received for contracted transactions into a common or standardized format. 
The common format facilitates identification of transaction data sets applicable to a contract 
term, and generation of contract-specific transaction data sets firom which performance of a 
contract term may be measured and from which performance reports may be generated. 
Accordingly, suppliers are more consistent and more accurate in their payment of discounts to 
customers. Also, the profitability of an account can be measured and tracked by all forms of 
revenue and talcing into account the discount payments. Further, compensation and incentive 
programs based on amounts and/or totals of contracted transactions may be structured for internal 
sales personnel. 

In yet another aspect of the invention, a method of generating a piirchase contract is 
provided. The method is particularly adapted for use with a method of managing purchasing 
contracts between at least one suppher entity and at least one customer entity, wherein the 
purchasing contract is applicable to one or more contracted purchasing transactions for products 
effected, at least partially, through a computerized system. The method of generating the 
contract includes the initial steps of collecting transaction data relating to historical purchasing 
transactions by the customer entity and/or satisfying a particular market profile, and storing, in 
one or more databases, a set of transaction data for each historical purchasing transaction. The 
method also includes the steps of defining one or more proposed contract terms and defining one 
or more temi attributes associated with each proposed contract tenn and storing the term 
attributes as a term data set in one or more databases. Then, the method requires the step of 
executing a computer program to quaUfy each proposed contract term. This qualifying step 
includes selecting one or more of the stored term attributes (e.g., total units requirement, or 
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and identifying each transaction data set that satisfies the 



The inventive method further includes forecasting a performance result of the proposed 
contract term using, as input, at least a portion of each transaction data set identified and 
qualifying the proposed contract term if the forecasted result satisfies a predetermined 
performance criteria in the form of one or more term performance rules. For example, three rules 
may apply. A first rule may require a specified share of a company's purchasing be made fi:om 
the supplier while a second rule may require a specified monetary amount be made firom the 
supplier. A third rule may require a specified unit amount of purchases be made firom the 
suppUer. Before a term is deemed acceptable, or thus qualified, it must satisfy one or more, or 
a combination of f these rules. Once terms are quaUfied, a purchasing contract incorporating one 
or more of the qualified terms is assigned between the suppUer entity and the customer entity. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a simplified system configuration diagram for the inventive system; 

FIGS. 2A-2C are simpUfied flow charts illustrating a method of generating a contract 
according to the invention; 

FIG. 3 is a simplified illustration of a plurality of databases which are generated and/or 
utilized according to the present invention; 

FIGS. 4A-4B are simpUfied block diagrams illustrating the generation of a data format 
for a contract-designated transaction, according to the invention; 

FIGS. 5A-5B is a simplified flow chart illustrating the creation of entity and contact 
databases, according to the invention; 

FIG. 6 is a simplified flow chart illustrating the creation of a term rules database, 
according to the invention; 
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FIG. 7A-7C are simpUfied flow charts iUustratingadatanonnalization process, according 
to the invention; 

FIG. 8A-8I are simphfied flow charts illustratmg a process of defining a contract and 
contract terms therefor, according to the invention; 

FIGS. 9A-9C are simplified flow charts illustrating a process of marking detailed 
transactions, according to the invention; 

FIGS. lOA-lOB are simplified flow charts illustrating a process of creating atransaction 
simmiary database, according to the invention; 

FIGS. 1 1 A-1 IB illustrates a process of forecasting term performance, according to the 
invention; 

FIGS. 12A-12B illustrates a process of forecasting contract performance, according to 
the invention; 

FIGS. 13 is a simpUfied flow chart illustrating a method of producing and distributing 
contract performance infomiation, according to the invention; 

FIGS. 14A-14B is a simplified flow chart illustrating a process of auditing discounted 
transactions, according to the invention; 

FIG. 15 is a simpUfied flow chart illustrating a process of the measurement of actual 
contract performance, according to the invention; 

FIG. 16 is a flow chart illustrating a process of final reconciliation of contract terms, 
according to the invention; 
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FIG. 17 is a simplified flow chart illustrating a process for the payout of the discount, 
according to the invention; 

FIG. 18 is a simplified flow chart illustrating a process of the measurement sales goals, 
according to the invention; 

FIG. 19 is an illustration of the exemplary use of detailed transaction data used for the 
purpose of contracting, according to the invention; 

FIG* 20 is an illustration of an exemplary Market Analysis Summary table according to 
the invention, according to the invention; 

FIGS. 21 A, 21 C are illustrations of a Term Definition Module, according to the 
invention; 

FIG 22 is an illustration of the financial forecast for terms and a contract; according to 
the invention; and 

FIG 23 is an illustration of a report monitoring actual performance of a contract, 
according to the invention. 

DETAIL DESCRIPTION OF THE DRAWINGS 

Definitions 

To facilitate description of the embodiment of the invention illustrated in the drawings, 
brief explanations of certain operative terms and concepts follow. These explanations should 
not, however, operate to limit the scope of the invention. 

As used heretofore, a "contract" establishes a legal relationship betweea a supplier entity 
(e.g., a suppUer, distributor, originator, or aUiance partner) and a cxistomer entity. A contract 
is characterized by contract attributes including one or more contract "terms." A "term" defines 
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an obligation on the part of one of the parties conditioned upon the satisfaction of term 
perfonnance criteria. The term is, itself, defined by "term attributes." 



The object of a contract between a supplier entity and customer entity are one or more 
"contract transactions" or "contracted transactions." These are transactions which effect the 
purchase of a supplier entity's product by the customer and which are governed by or apply to 
the contract. Records of these contract transactions include information related to the contract 
including a unique customer identifier, a unique contract identifier and contract term identifier. 
Identification of a specific contract transaction requires that information about the transactions 
be individualized. Sometimes, a record of a contract transaction will actually contain more than 
one contract transaction (as defined by the contract), i.e., aparent transaction. This information 
needs to be individuahzed to obtain each of the individual contract transactions. Conversely, a 
record may contain information that does not adequately identify the transaction as a contract 
transaction, i.e., a partial transaction. Similar to the parent transaction, this transaction must be 
individualized to obtain the individual contract transaction. 

A "data set" is a collection of related information or data. A data set may reside on 
electronic storage media in a database or the data set may reside in the memory of the computer. 
A data set may comprise data stored in a plurality of databases but which are somehow 
associated for electronic access purposes. As shown herein, the data set may be displayed as 
rows in a database table. 

A "definition" as used herein (e.g., "market definition", *term definition", "contract 
definition") may refa: to the criteria that describes these items that are stored in a database in a 
computer language format, such as Structured Query Language. 

A "data format" may refer to the unique collection, representation and arrangement of 
data in a data set. Typically, the data represents attributes. Although attributes are usually found 
within a row of a data set arranged in a particular order, the attributes may be arranged in any 
manner so long as the particular attribute type and value can be identified. 
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A "database table" as used herein refers to a means of storing structure data in an 
electronic media accessed by computerized processes. 



An "identifier" is a data value or a combination of values that uniquely reference a 
particular entity or subject such as a Supplier, Customer, Contract, Contract Term, etc. The 
identifier may be any combination of characters, numbers, or any other representation so long 
as the value establishes the entity. 

A "software module" or "module" as used herein means a component of the system that 
carries out instructions, rules, and processes of the inventive application. 

"Structured Query Language" (SQL) is one form of computer language used to store 
structured commands to a database. 

A *tenn rule" is an attribute that defines a performance requirement or criteria which 
must be satisfied before a contract term is deemed satisfied or fiilfiUed. In generating a contract, 
a proposed contract term may be required to satisfy, e.g., based on historical data, a specific term 
rule. For example, a term rule may be set up that specifies a numerical amount of product imits 
purchased, a total purchase value or monetary amount, a percentage or share of purchased units 
or total purchase value. In other words, before a contract is created or quaUfied, each contract 
term may have to meet the specific requirements of the term rule. These term rules can later be 
used as a performance or term parameter to gauge the performance of the particular contract. 

The following terms are used to describe the system and inventive method's application 
in the travel industry. 

A "Directional Pair" describes the originating and destination airports but counts the 
originating airport twice. For example, a round trip between San Francisco (originating) and 
Chicago is indicated by the code SFO-ORD and recorded twice (as 2 flights). 
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*Tront-end Tenns" are contract terms which provide for a discount to the customer 
discount at the point of sale. 

''Back-end Terms" are terms which, if satisfied, provide payment of the discount to the 
customer at the end of a contract period. 

'*Host" or 'Host Carrier" is the contracting airline operating the system. 
A 'Market" as used herein, refers to the passengers true origin-destination on the same, 
or alliance carrier, which may be comprised of multiple segments (i.e. ABQ-HOU-AMS). 

The 'Market Share Database" is a summary database containing values establishing the 
minimum share the carrier requires for any market (to meet a contract tenia) . 

An "OD Pair" is an origin and destination pair describes the originating and destination 
airports in alphabetical order of the origmating airport. ODPairs are used to count the total 
nimiber of flights between two airports. For example, a round trip flight between San Francisco 
and Chicago is indicated by the code ORD-SFO and recorded twice (as 2 flights). 

Exemplary Application In a Common Carrier Industry 
The present invention is particularly adapted for implementation in the operating 
environment of the airline industry or other coimnon carrier industry. Airlines enter into 
contracts with companies for the volume purchase of airline seats at discounted prices for 
business travelers. The terms of these contracts may require commitments for the purchase of 
a specified number of seats, or the expenditure of a monetary amount, or a designated share of 
a customer company's purchase (count or monetary amount) to be dedicated to the airline. 
Accordingly, these contracts can represent large financial commitments by customers and 
involve significant ticket price discounts. 

Airlines typically measure contract term performance by examining reports or data 
provided by the customer; or require a travel agency to manually input a term code in a travelers* 
data record; or rely upon internal data that are exclusive to the airline, such as revenue accounting 
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data. The product data acqxiired are often raw and not in readily usable form for some contract 
management tasks. Typically, the mformation initially collected are in flight segment data form 
which does not properly reflect the traveler' s ultimate destination. Among other things, the form 
of this data and the means by which the data are collected do not readily allow for a transaction 
to be matched or identified with a contract term (so that measurement of the contract term's 
performance reflect the occurrence of these transactions). 

Moreover, without agent intervention, the record of these transactions do not 
automatically or readily indicate information relevant to a contract term such as the count of 
seats, amount of expenditure, the airline's share of business, and other transaction information 
or values. Contracted terms and fares are inconsistently displayed in the various airline booking 
databases. Agents typically enter special codes to designate fares and thus, since this is a manual 
operation, the information entered is often incomplete or inaccurate. Additionally, agents enter 
codes which apply to only one specified carrier, and which caimot be associated to other carriers. 
As a result, the measure of term performance may be inadequate since the total number of 
passengers, total expenditure, and share of flights for a given company may not take into account 
flights on other airlines. Thus, the inventive system and method provide for the collection, 
identification, and/or generation of transaction information or data which facilitate the 
measurement of contract performance for all carriers. 

Airlines are also extending their reach to new markets by forming airline alliances 
comprised of two or more carriers. An airline within an aUiance may "code-share" which is the 
practice of using the flight number or code of the alliance partner in addition to its own flight 
numb er or code. While a traveler' s itinerary may show one airline to a destination, more than one 
airline may actually be flown. In a multinational setting, contracts often apply to code-share 
flights. Therefore, in one aspect of the invention, the inventive system and method are adapted 
to identifying transactions involving code-share flights with a contract term and/or converting 
transaction data relating to such flights into a form that is suitable for the management of a 
contract (including measurement of a contract term). 
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Airlines distribute theirproducts (airline seats) through electronic systems such as Global 
Distribution Systems, travel agencies, or Internet booking portals. Tickets may be purchased 
through any one of thousands of travel agent ticketing locations located around the world. While 
ticket data may be collected in airline revenue accounting systems or in travel agent accounting 
systems, many of such systems create and use incompatible data formats. Thus, an airline 
examining data made available to it may not be able to recognize that a traveler is qualified for 
a corporate discoimt. Moreover, when airlines do recognize such a traveler or transaction, 
identifying tickets which qualify for discounts is done by entering a unique number into a 
computer system. Again, since this step is performed manually, it is subject to error. The 
present invention provides a system and method for identifying ticketing transactions applicable 
to a contract between airline and a customer company; collecting transaction data therefor, and 
storing and/or converting all of the transaction data in a common format. The stored/converted 
data may be referred to as transaction data sets and may be fbrther manipulated or marked so as 
to be identifiable with a contract and/or contact term, or used for evaluating or qualifying 
proposed contracts or contract terms. 

Accordingly, Figures 1-23 and the detail description of these Figures relate to an 
application of the inventive system and method to a contractual relationship between a supplier 
entity such as an airline company or its distributor, and a customer entity such as a large national 
corporation. The products which are the subject of the contractual relationship are seats or 
flights. These seats are identifiable by carrier, seat number, cabin class and flight segment (i.e., 
origin-destination or OD). The application of the inventive system and method to other types of 
contractual relationships will become apparent to one skilled in the art upon reading the 
description and/or claims and/or viewing the drawings, all provided herein. 

Overview of Figures 

FIGS. 1-23 depict systeins and processes embodying various aspects of the invention. 
More particularly, FIGS. 1-23 illustrate one ormore inventive systems and methods particularly 
adapted for xise with or in regard to a purchasing contract between a suppUer entity such as a 
common carrier (e.g., an airline company) or a distributor (e.g., a travel agency) associated with 
the coimnon carrier, and a customer entity such as a large corporation. 
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Among other functions, the systems and processes illustrated in the Figures and described 
herein provide for the following functions: (1) identify and record information on business 
entities and contacts; (2) define perfonnance term rules indicating the minimum and maximum 
financial performance requirements for the term and the contract; (3) acquire and nonnahze 
historical customer purchasing data; (4) input contract terms and forecast financial performance 
of the term and contract; (5) produce contract and t&rm requirement documents; (6) mark current 
transactions by unique contract and term codes and produce a database to analyze contract terms; 
(7) produce performance information for suppUer and customer persoimel; (8) initiate customer 
discounts; and, (9) reconcile term requirements to term performance at or near the end of the 
contract In one .aspect of the invention, each of the above functions are provided automatically 
or by implementation of computerized processes. Some of the modules employed in a computer 
system and software embodying the invention are discussed herein for illustrative purposes. 
These modules are particularly adapted for employment by a representative of the supplier entity 
(e.g., airline). 

Preferred Svstem Configuration 
FIG. 1 is a simplified system configuration diagram illustrating a system 1 09 with which 
various steps or subprocesses of tlie inventive method may be implemented. These steps and 
subprocesses are implemented by executing a program that resides on a computer or application 
serverl03 (operable with a system administrator station 103a) connected via a network 105 (and 
network access device 105a) to a database server 101 having retrieval and storage access to 
appUcation databases 101a. This allows the inventive processes(s) to be implemented in a 
client/server or multi-tier configuration. In one embodiment, the program runs on a computer. 
However, the program may also run on any other network connected device 107 capable of 
processing, displaying, and receiving data and transmitting the data over the network (e.g., 
cellular telephones, agent terminals, airline ticketing terminals, diskless workstations, personal 
data assistants, etc.). The database(s) are connected via a computer network 105 to the computer 
or the application server 103. Although in the preferred embodiment, the database resides 
separately firom the computer, the database may reside on the same computer as the program. 
The computer network 105 shown is a local area network 105, but may also be any type of 
network capable of handling electronic communications between two devices on the network 
(e.g., the Internet, Wide Area Networks, Cellular networks. Microwave networks, etc.). The 
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computer network 105 may have any arbitrary topology and can be comprised of a number of 
computers as well as network devices such as switches, routers, gateways, firewalls, etc., and 
other resources such as file servers, printers, etc. 

General Method Of Generating a Purchasing Contract 
FIG. 2 illustrates a flow chart generally describing a preferred set of steps for generating 
a purchasing contract according to the invention. The initial step of the method includes 
proposing a contract (201) between one or more suppHer entities and one or more customer 
entities (although in the presently described method, the contract involves a supplier entity such 
as an airline and a customer entity such as a large national corporation). The inventive method 
will require the creation of, access to, and/or storing preliminary information in one or more 
databases. For example, the method includes the initial step 203 of creating a contract Entity 
Database, which entails collecting information on the supplier and customer entities and storing 
data relating to or representing this information in the Entity Database 303. Next, an entity 
Contacts Database 305 is created (205) which entails collecting information regarding employee 
contacts Avithin the customer entity and information on the employee within the supplier entity 
assigned to the contract, and storing this information as data in the entity Contacts Database 305. 
Further, certain ancillary databases 403 are also provided (207) for purposes, which will be 
described below. 

In another preliminary step 209, the proposed contract terms for the contract are defined. 
Such contract terms may be similar to terms in other contracts made between the supplier and 
customer entities, or between the supplier and other customer entities. The contract terms will 
have associated therewith certain contract term attributes (e.g., term performance criteria, 
discount, etc.). These temi attributes are stored as a term data set 21 1, unique to tlie contract 
term, in the Term DefinitionDatabase 315. Additionally, the proposed term will have associated 
therewith term performance rule(s), which will be explained fiirfher below. These term 
performance rales are stored in a subsequent step 213 in a Term Rule Database 313. 

Upon establishing the above parameters for the contract and contract terms, certain steps 
are taken to forecast and qualify the contract terms for the contract, and thus to produce the 
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contract. Accordingly, the next step in the method is the step 215 of collecting historical 
transaction data (i.e., by the customer entity for the same or similar products which are the 
subject of the proposed contract). As mentioned previously, such transaction data may be in a 
form that does not correspond with the product unit(s) that the supplier entity, its programs or 
systems is familiar with. In addressing this, the inventive system individualizes the transaction 
data sets which are collected (217). This may involve deriving one or more individualized 
transactions from a parent transaction, or identifying less than a whole (percentage) of an 
individualized transaction from such a parent transaction. After collecting the transaction data 
sets, these transaction data sets are, in a ftirther step 219, converted into a standard format and 
stored in a Transaction Detail Database 307. 

In what may be referred to as the next stage in this method of generating the purchasing 
contract, certain of the proposed contract terms are qualified. In an initial step 221, one of the 
proposed contract terms is selected. This is followed by a step 223 wherein transaction data sets 
in the Transaction Detail Database 307 are examined such that those data sets which are 
identifiable or apphcable to the proposed contract term are marked. Having identified the 
collection of the appropriate transaction data sets, the proposed contract term may be defined 22 5 
and then tested. Fiutiier, the performance of the term is forecasted using, as input, data from the 
identified transaction data sets. The forecasting step generates certain performance values or 
expected performance values and which are then (in step 229) compared to the appropriate term 
performance rules from the Term Rule Database 3 1 3 . If, based on this comparison, the proposed 
term is deemed quaUfied; the method assigns a unique term code to the quaUfied term (23 1). 

Upon quaUfication (or non-qualification) of the first term, the method further includes 
a step 233 of selecting another contract term, if desired, and qualifying that term. 

After all of the selected proposed contract terms have been qualified, the method 
computes the financial result of the proposed contract with one or more of the qualified proposed 
contract terms (235). Based upon the results ofthis computation, the contract is either approved 
or disapproved (237). If the contract is approved, the contract and its contract terms are produced 
(239). Based on the contract type, the system selects the correct contract and produces a shell 
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contract including the correct name and address of the business entities and signatories to the 
contract. Then, using data from the Contract Term Database, a term sheet is produced in 
standard language that mirrors precisely the term requirements stored in the computer. 

The above is a brief, general ovendew of one genial method according to the invention. 
The various subprocesses of this method and related methods are described in more detail in 
certain sections of the description below and in respect to an airlines industry application. 

Computer Svstem Databases 

FIGS. 3 and 4 illustrate tlie various databases which may be generated or utilized by a 
preferred system or software package according to the invention. The following are introductory . 
explanations of each database. 

1. The Entity Database 303 contains fact information relatmg to customers, 
suppliers, distributors, airlines, alliance partners and other entities. Information on these entities 
include legal business name, address, phone numbers, and tax nimiber. 

2. The Contacts Database 305 contains information relating to persons involved in 
transactions or contracts. These persons include persons who are responsible for sales, customer 
management, or purchasing contracts, 

3 . The Transaction Detail Database 307 contains information relating to a collection 
of purchasing transactions by a customer arranged in a common or standardized format. Each 
set of ioformation or data may be referred to herein as a transaction data set. 

4. The Transaction Summary Database 309 contains sunmiary information relatmg 
to certain detail transactions stored in the Transaction Detail Database. Creation and use of this 
database is described in detail below. 

5. The Contract Registry Database 311 contains information relating to contracts 
which have been created, i.e. through implementation of the invention. 
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6. The Tenn Rule Database 313 contains information relating to operator defined 
terms and include term requirements for minimum or maximum purchase amounts, supplier 
share, or the number of units to be purchased. 

7 . The Term Definition Database 315 contains information relating to the agreement 
for performance between the supplier and the customer. Some of the term attributes which are 
contained in the database includes items such as term effective dates, performance requirements, 
discount mformation, etc. 

8. The Tenn Performance Database 317 contains simmiary information related to 
a particular term including such information as total unit counts, total amounts, supplier shares, 
and requirement status. 

9. The Payment Database contains information relating to payments made for 
performing terms including payment schedule, start and end dates of payment period, payment 
amounts and discount amounts. Once the system determines that the requirements for a term are 
met, the Payment Database is used to process and record payments. These payments are also 
used in determining the actual discount paid and in computing the final financial performance 
of the contract. 

10. The Sales Goal Database 319 contains information relating to specific 
performance related goals set by an entity such as a supplier. 

1 1 . The Supplier/Distributor Database 40 1 'contains information relating to entities 
which provide products (e.g., goods or services). Supplier Entities can be entities such as the 
supplier, distributor, and affiUates of the supplier. 

12. The Ancillary Database(s) 403 include one or more databases, which contain 
various information relating to flight segments, product and marketing information, operating 
carriers, actual flight pricing, arrival and departure times, and other information. The ancillary 
databases provide information that is in the public domain, but fi-equently contain data that are 
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more reliable than data collected with the transaction. When the data do not match, the most 
reliable source is used. 

The above databases may be provided on a single electronic storage medium or multiple 
electronic storage media, and linked/interlinked in communication with one or more processors 
301. Although, the databases are shown as separate databases in the preferred embodiment, the 
databases may be created as a single database containing some, all or part of the information 
found in the other databases. In any event, a system or software embodying the invention will 
be able to create and/or access one or more of these databases. 

Contract-Designated Transaction 
Once the parties have agreed on their intent to negotiate a deal, the customer provides the 
supplier with detailed data for each purchase. Often these data are from disparate sources and 
arrive in incompatible formats. The inventive system and method sequesters data into a 
temporary database before it normalizes tlie data into a common transaction format. Data may 
reflect components of the actual purchase in which case the components must be constructed to 
reflect the actual (or whole) purchase, or data may reflect a transaction that comprises more than 
one product in which case the transaction must be deconstructed to identify the product. In either 
case, the inventive method performs the subprocess of individualizing transactions or transaction 
data. 

Using the databases previously described, namely the Supplier/Distributor database 40 1 , 
the ancillary database 403, the Entity and Contacts Databases 303, 305, the Contract Registry 
Database 311 and the Term Definition Database 3 1 5 , the inventive method generates a new class 
or collection of data sets that ties the transaction to the various aspects of the contract (see FIG. 
4). The following data elements (attributes) may be acquired for each customer transaction: a 
descriptive code of the item purchased at the terai level; the date and time of purchase; count of 
units pmrchased; net and gross amount of the purchase; supplier's unique code; and, the 
distributor's unique code. These data elements are then used to lookup and derive information 
from the databases identified in FIG.4. Upon lookup and derivation of infomiation from the 
various databases, the new class of data 409-415 is automatically created. The new class of 
transactional data in the preferred embodiment contains or represents the following attributes: 
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Product Description (405) 

Product Code(s) 
Supplier Code 

Distributor Code 

Unit(s) 

Cost 

Date & Time of Transaction(s) 
Entity and Contact Information (407) 

Supplier Entity 
Supplier Contacts 

Distributor Entity 

Distributor Contacts 

Customer Entity 

Customer Contacts 
Contract Information (41 1) 
Contract Code 

Term Code 

Transactional data may be analyzed by contract criteria embodied in the Term DejMtion 
database that includes the data elements which define the contract term. 

Term Requirement Information (413) 

Market, Product, Class Requirement 

Market Product, Class Discount 

Begin and End Dates 

Unit requirement and/or 

Cost requirement and/or 

Share requirement 
Term Performance information (415) 

Count 

Amoimt ^ 
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Share 

Discounted and undiscounted amount 
The system processes that create these data are illustrated in FIGS 5-18 and described 

below. 

Input Contract Entities and Contacts 
When an airhne and a customer first discuss the possibiUty of a deal, the business entities 
in the proposed deal are identified. Entities may include the corporate or agency customer, the 
airline, and the airline's potential alliance partners. Facts on each party are required for the 
contract such as legal business name, address, and tax number. The inventive system stores this 
data in an Entity Database 303. While contracts are between entities, individuals are responsible 
for the management of the contract. Airlines assign individuals who are responsible for sales, 
customer management, and contracting. Likewise, companies assign individuals who are 
responsible for purchasing and contracting. Information on these individuals are stored in the 
Contacts Database 305. 

The flow charts illustrated in FIGS. 5 A and 5B provide the creation (or update) of the 
entities and Contacts Databases 303 and 305. The process begins with the operator inputting 
contract entity data (501) and inputting supplier data (503). SuppHer entity and customer entity 
data may include such information as legal name, address, phone, email address, and web site, ' 
Further, the customer information may include such additional information as corporate division, 
industry, and applicable sales region. A determination (505) is then made whether another 
supplier is to be added. If so, the operator inputs supplier data for that supplier and for 
subsequent suppliers until no more suppUers are to be added. The operator inputs distributor data 
(507), which is followed by a step 509 of determining whether another distributor is to be added. 
This is followed by operator inputting distributor data for that distributor and for subsequent 
distributors until no more distributors are to be added. The operator inputting data source data 
(5 1 1) for a first data source, and, if it is determined (513) that there are additional data sources, 
for each of those data sources as well Upon completion of the above steps, the entered data is 
stored in the Entity Database 303 (step 527). 
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FIG. 5B further illustrates the creation of a database 15 that may be characterized as 
another Entity database. The Entity Contact Database 305 contains information regarding the 
sales person responsible for the contract, employees of the supplier entity and employees of the 
customer entity who are relevant to the contracts or contract terms. First, the identity of the sales 
person responsible for the contract is entered (515). Next, the identity of the customer contacts 
are established (517). Then, employee or personnel contacts within the customer entity are 
identified followed by the step of loading or inputting contact data into the Contact Database 
305. Contact data may include such information as the name of customer(s), address, phone 
numbers, and personal information for work and home. In the case of generating a proposed 
contract and contract terms, the customer information will relate to a potential customer and the 
potential customer's employee(s). 

In a second step 519, supplier entity employee data is loaded into the Contact Database 
3 05 . This step is preceded by a step of identifying supplier entity employees who are responsible 
for the contract or proposed contract. This identification step preferably includes associating a 
fimction and/or hierarchical position to each employee (e.g., sales supervision, contracting, 
payment). The contact data loaded will, of course, include such information as name, address, 
phone numbers, and personal information for work and home. The subprocess may fiirther 
include the. step 321 of collecting and inputting distributor contact data, when applicable. 
Additionally, the subprocess preferably includes the step 523 of inputting data source contacts 
and entering the names or designations of responsible personnel for providing transaction data 
on what has been purchased. All of these data is then stored in the Contact Database (305) (step 
525). 

Establish Contract and Term Rules 
The process of term qualification is conducted by matching or comparing the financial 
results obtainable with a proposed contract term (e.g. based on historical transaction data) to 
predefined term criteria or term rules. These rules are operator defined and may include 
requirements for minimum or maximum purchase amounts, supplier share, or the number of units 
to be purchased. 
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The flow chart of FIG. 6 illustrates in simplified form a process of inputting, and thereby 
creating, tenn rules in the Term Rule Database 313. In a series of steps, the minimum and 
maximum values for the supplier share and the minimum and maximum values for unit count 
are inputted (60 1 , 603). Then, the minimum and maximum values for gross revenue amount and 
the minimimi and maximum values for net revenue amount are inputted (605, 607). These steps 
may, of course, be performed in various orders or sequences. The term rule definitions are then 
stored in the Term Rule Database 313 (step 609). 

Normalize Data into Standard Transaction Format 
It should be noted that, in one respect, the new class of data 409 (or contract-specific 
transaction dataset)is derived from at least three other data sets: a transaction data set307, entity 
data set 303, contact data set 305, and contract data set 3 1 1 , and term data set 3 1 5. The creation 
of each of these data sets is fiurther described below. 

Airline data is derived from travel agencies, Global Distribution Systems, third-party data 
consolidators, or the airline's internal sources. The data is exported from distributor's sales 
information systems in different fonnats, A first subprocess of the inventive method is to collect 
transaction data from such various sources and to convert (i.e., normalize) the collected 
transaction data into a transaction data set 307 stored in accordance with a common format. 

Data taken from the point of sale may not reflect the individual items measured in a term. 
Point of sale data may comprise individual product components that must be constructed into the 
appUcable unit product purchased in a term, or point of sale data may comprise multiple 
contracted products that must be deconstructed to identify the individual product. In either case, 
the true item being measured by the tem must be constructed (or de-constructed) from the data 
provided. Airline systems store product data as flight segments. Using standard industry 
practice, the many segments that comprise an itinerary are constructed into origin and destination 
rows (ODs) reflecting the true destination the traveler, or a group transaction may include many 
travelers, in which case it is deconstructed to provide one transaction per traveler. Ancillary 
databases 11 are used to confirm the accuracy of the data, e.g. to determine, or correct, the 
designation of the carrier, the actual price of the flight, or the arrival and departure times. 
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Typically, if the transaction data dififer, data in the ancillary database are given preference and 
written in. Once the data is converted into the standard format, it is loaded into the Transaction 
Detail Database 307. Then, refunds and exchanges are netted against the original transactions 
so an accurate transaction count is maintained. Once the data is normalized, it is ready for 
contract term modeling and the quaUfication of financial performance. 

The flow chart diagram in FIGS. 7A-7C illustrates in simplified form a preferred data 
normalization process (i.e., a process of receiving transaction data and storing at least a portion 
of the data in accordance with a common format). The process begins with steps 701-71 1 of 
inputting the following information: a comt of units of product purchased, a cost of units of 
product purchased, a unique code or identifier for the product, a xmique code or identifier for the 
customer, a unique code or identifier for the supplier, a unique code for the distributor. Then, 
the input data or data set is compared with information in the ancillary databases 403 (step 713). 
If the input data does not match or correspond with data in the ancillary database 403 or satisfy 
some other identifying criteria stored therein, the correct elements in the data set are then used 
to lookup and correct the incorrect elements (715). For example, if the value for the departure 
time of a flight for the data source differs firom value in the authoritative ancillary database, the 
value from the ancillary database will be used to over write the incoirect value. 

If the input data does match, it is determined whether the product description represents 
the unit the customer purchased (717). If the product does represent the unit the customer 
purchased, then the process continues by loading data into the Transaction Detail Database 307 
(step 727). If the product does not represent the unit the customer purchased, then it is 
determined whether the transaction is a component of the product purchased (719). 

If the transaction is found to be a component of the product purchased, the true product 
is first constructed firom the data 72 1 before the process continues witli the loading the data (527) 
into the Transaction Detail Database 307. If the transaction is not a component of the product 
purchased, it is determined whether the transaction is comprised of multiple products (723). If 
the transaction is not comprised of multiple products, the data is loaded (727) into the 
Transaction Detail Database 307. If the transaction is comprised of multiple products, however, 
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the true product is first deconstructed from the data (725). Either of the above series of steps is 
referred to as indi\ddua1izing the transaction data set collected for a transaction. For example, 
more than one traveler may be indicated on one airline ticket. Each traveler represents one p erson 
traveling to that destination, and each traveler may receive a contracted discount. The system, 
therefore, creates and stores an individual transaction for each individual traveler (although one 
ticket was issued). 

Now referring to FIG. 7G, the next step 729 in the method is determining whether the 
transaction is an exchange. If the transaction is found to be an exchange, a pseudo refimd is 
issued for the exchange (731). A refund is issued to cancel the original transaction. This is 
critical for the true net transaction count. Then, in the next step 733, or if the transaction is not 
an exchange, it is determined whether the transaction is a refund. If the transactionis a refund, 
the transaction is marked (73 5) as a refund and the original transaction is identified. Then, if the 
transaction is not a refimd, the method proceeds directly to loading the data (step 737) into the 
Transaction Detail Database 307. 

Define Contract and Performance Term 

Purchasing contracts axe agreements between supplier and customer. Performance 
requirements for the contract are stated as one or more contract terms (which are one of the 
contract attributes). In one aspect of the invention, the method enables the user to input and store 
these terms in the computer as Stmctured Query Language (SQL) definitions or its machine 
language equivalent. Thus, by using the SQL definitions, the computer can readily compare the 
data elements associated with the term requirements with corresponding data elements associated 
with a product purchase, i.e., the transaction. When the data elements match, the contract and 
term are automatically identified and marked. Each term may include, as its attributes, a unique 
title, beginning and end dates for which the term is effective, performance requirements, discount 
amount and method (e.g., if term is satisfied), special purchasing uistmctions, a user-defined 
code for the term, and identification of the distributors who are authorized to sell the product at 
the stated discount and how much they are compensated. Each contract is also given a unique 
code. Likewise, terms are given a unique code that groups them under the appropriate contract. 
SQL definitions for a term are stored in the Temi Definition Database 315. 
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By using the term definition, the inventive metiiod can identify each transaction or data 
set in the Transaction Detail Database 307 with a designated unique contract code and terra code, 
as well as the appropriate entity codes. In this way, a collection of contract-specific transaction 
data sets are generated. Further, the inventive system and method provides a supplier entity an 
improved means of storing a unique class of information pertinent to a supplier-customer 
contract and, a means of generating, firom data sets representing this information, transaction 
summaries and contract measurement reports. 

FIGS. 8A-8I illustrate a method of definmg a proposed contract and its contract terms for 
use in a supplier-customer environment of the airline industry and designated for a customer such 
as large national company. The steps of the preferred method are implemented through various 
operations of inventive software by an operator representative of the suppUer entity. In FIG. 8, 
tlie method is initiated by accessing or starting a Contract Definition module of the software and 
prompting the program to start a contract definition operation (801). The user selects and enters 
a name of the proposed contract name (803) and then the beginning and end dates of the 
proposed contract (805). Next, the user selects one of several choices of contract types provided 
on the module (807). The selections may include: agency; agency cluster; alliance; corporate; 
corporate cluster; meeting; or combinations of these. In yet another aspect of the invention, the 
user may enter more than one participating supplier (i.e., carriers) and identify these suppliers 
with the proposed contract. Among other things, this allows customer purchases of tickets on 
carriers which are not the primary carrier for the contract or customer but can be later credited 
to the customer and the customer's contract. Then, the program assigns the proposed contract 
a unique identification code (8 1 1) and stores the contract description (which include the unique 
contract ID and the rest of the above-entered information) in the Contract Registry Database 311 
(8 1 3). The information provided above is, therefore, accessible by using the contract's unique 
identifier. 

Preferably, the operator will access a second module to initiate the definition of the terms 
for the contract (8 1 S). In initial steps, the operator enters a title or description for the term to be 
defined (8 17) and the beginning and end dates within which the term is to be appUcable (819). 
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The system then assigns the term a imique identiJ&cation code (step 821) and stores a term 
description in the Term Definition Database 315 (step 823). 

Referring to FIG. 8C, in a subsequent stage of the method, measurement criteria is 
defined for the contract terai. The term measurement criteria is used to identify which historical 
transactions or records are to be identified with the term and thus, used to measure the 
performance of the term. FIG. 21 A provides a screen shot of a module 2101 used to define the 
performance measurement criteria of a proposed term. After initiating the process (step 825), 
the operator enters the markets for measurement (step 827) and then, the suppliers (step 829), 
products (step 83 1), and the classes (step 833) applicable to the term. For example, in the airline 
industry contract, markets are identified by flight origin-destination pairs, such as Washington, 
D.C.,-Chicago, O'Hare (lAD-ORD). Products are seats on the flight types which may be 
identified as non-stop, one-stop, or direct. Classes of service ,or cabin type, maybe identified as 
first class, business, economy and discount. The term measurement criteria are then stored as 
a SQL statement in the Term Definition Database 315 (step 835). 

Next, the system queries whether measurement exclusions are to be defined (839). These 
exclusions are used to identify transactions which are not to be used in term performance 
measurement (but may, otherwise, qualify under the measurement criteria). Referring to FIG, 
8D, the measurement exclusion definition process is initiated by the operator. The operator 
defines flie transactions to be excluded by specifying the market(s) to be excluded (step 841), the 
supplier(s) to be excluded (step 843), and the product(s) to be excluded (step 845), and/or the 
class(es) to be excluded (step 847). The resulting measure-on exclusion criteria are then stored 
as an SQL statement in the Term Definition Database 315 (step 849). 

If there are no exclusions to the performance measurement criteria to be defined or all 
such exclusions have been defined, the operator begins definition of the discount payment criteria 
(85 1) by accessing the appropriate payment criteria module (see, e.g., FIG. 21 C), The payment 
criteria provides the means by which to identify those transactions for which a discount is to be 
applied. The operator defines the payment criteria by entering the required market(s) (step 853), 
required supplier(s) (step 855), required product(s) (step 857), and/or required class(es) (step 
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859) for transactions to be discounted. The system then stores this information as SQL statement 
in the Term Definition Database 315 (step 861). 

As with the term measurement criteria, the system also allows the operator to define 
payment exclusions (865), thereby identifying the ticketing transactions for which no discoimt 
will be applied. The operator initiates this process (see FIG. 8F) also through operation of the 
payment criteria module. Then, the operator enters the market(s) (step 867), the supplier(s) (step 

860) , the product(s) (step 871), and/or the class(es) (step 873) defining those transactions for 
which no discount is to be paid. Then, the payment exclusion criteria is stored as an SQL 
statement in the Term Definition Database 315 (st-ep 875). 

Term definition according to the invention also requires distributor related expenses to 
be accoxmted for. Airlines pay distributors, such as travel agents and credit card companies, 
commissions for talcing reservations and selling airline tickets, and processing payments. In the 
inventive method and system, these payments can be accounted for when analyzing a contract 
term or contract. The user can define the term to include or exclude distributor commission, and 
to define the ticketing locations that are permitted to sell tickets with the discount. 

Referring to FIG. 8G, the operator initiates definition of these distributor-related 
expenses or distributor compensation using the term defijoition module (step 877). For each 
distributor, the operator enters the distributor's commission amount for each ticket (step 877), 
any distributor override amount or additional incentive commission that is paid or credited to the 
distributor (step 879), and any credit expense (i.e., credit card transaction fees paid to the credit 
card companies) by the distributor (step 891). The above are amounts ordinarily deductible fi-om 
revenue generated from the ticket transaction and not received by the airline supplier. Thus, 
these amounts may not be measured in the term's performance. The distributor compensation 
criteria are then stored as an SQL statement in the Term Definition Database (step 883). 

Now referring to FIG. 8H, the system fiirther allows the operator to defme the discount 
payout criteria, still using the term definition module (step 855), The operator defines the 
discoxmt payout criteria by first selecting the payout timing (885), which may be selected to 
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occur at the point of sale or at the end of one or more periods (step discount). Next, the operator 
selects the performance or purchase conunitment requirement for the term, which may be entered 
as a share of count (total of customer's or suppher's transactions), share of total expenditure, or 
total count of transaction (or product units) or dollar amount for transactions (887). Then, the 
operator selects the discount type to be employed, which may be a percent of the transaction(s) 
amount, a fixed price, or flat amount off (889). 

If the payout timing selected is end-of-period, as queried to the operator (891), the 
operator is prompted to define another step 893, in which case the operator returns to step 887 
to select the performance requirement for the next step. Otherwise, if the payout timing selected 
is end-of-period, the operator is queried as to whether there is another payout date and to define 
the applicable payout dates (894), until all payout dates are defined. After the payout periods are 
defined, or if the payout timing selected is point of sale, the operator has the option to enter codes 
used by the distributors to tock product inventory in other management systems (896). The 
results firom these criteria are stored as an SQL statement in the Term Definition Database 315 
(step 897). 

With the above information for proposed contract and its terms, the financial performance 
of each term can now be tested or projected (see process illustrated in FIGS . 1 1 A-1 IB (step 898)) 
and the financial performance of the overall contract may be tested or projected (see process 
illustrated iii FIGS. 12A-12B (step 899). 

Marldng Detailed Transactions 
In an electronic environment wherein many purchases occur firom many sources, and 
perhaps firom many distributors, it is advantageous for supphers to be able to predict the financial 
performance, or profitability, of their contracts. Accordingly, the present system and method, 
using criteria firom the Term Definition Database (315), marks each transaction in the 
Transaction Detail Database with its unique entity codes, contact codes, contract code and term 
code. In doing so, the inventive method creates a new class of data or collection of data sets that 
ties the transaction to the various aspects of the contract (i.e., see FIG. 4). These 
contract-designed or contract-specific transaction data sets are then used to create unique 

28 



wo 01/75745 



PCT/USOl/10798 



business processes throughout the inventive systems and methods. For example, processes are 
employed to qualify, monitor, pay discounts, and reconcile the financial performance of the deal. 

During the course of the contract, the customer agrees to provide data to the supplier to 
measure purchasing performance. These data are consolidated and normalized in transaction data 
sets as described in detail earlier. As transactions are loaded into the TransactionDetail Database, 
the computer executes a routine that employs the SQL term definitions for the Term Definition 
Database 315 to mark each term with its unique entity codes, contact codes, contract code and 
term code. The inventive method computes the summary totals for each term iacluding the total 
unit count, total amount, suppHer share for the period measured, and whether the term 
requirements were met or not. These data are loaded in the Term Perforaiance Database 317. 

In an exemplary subroutine for collecting current airline transactions and marking the 
transactions applicable to a specific contract, the databases illustrated in FIG. 3 are utilized. The 
result of the subroutine is an OD transaction table listing each OD as identified with the contract 
information it meets. From the contract term table, the time of purchase or end of term discount 
contract term ID and contract ID are applied to the OD rows which are to be marked. The query 
ID defines tlie OD rows which are to be counted towards the requirement (this value may be a 
percentage, count or monetary amount) of the contract term. The financial query ID defines OD 
rows which are to receive the specified discount of the contract temi. It is noted that the query 
ED and financial query ID are separate and may define different OD rows. 

Furthermore, only the OD rows which are within the begin (departure) and end dates of 
the contract term, and which are associated with a company or company clients specified by the 
contract term are marked. The subroutine begins by selecting firom the contract table a contract 
that is active and which has contract begin and end dates that encompasses the subject date range^ 
for the ODs. Then, a temporary table is created to hold all transaction numbers (associated with 
ODs) which match the contract date and the ticket company and agency for the contract. Then, 
the ticket source company and the ticket customer company are identified based on the contract 
type (i.e.. Agency, Agency Cluster, Alliance, Meeting or Corporate, or Corporate Cluster). 



29 



wo 01/75745 



PCT/USOl/10798 



FIG. 9 illustrates, in simplified form, aprocess of collecting current detailed transactions 
and marking certain of the detailed transactions with the appropriate or designated customer, 
contract, and term codes, thereby generating a collection or set of contract-specific data sets. 
Initially, the system loads current normalized transactions into the Transaction Detail Database 
307, and retrieves the appropriate term criteria from the Term Definition Database 315. This 
begins the comparison of each detail transaction row with the term criteria. First, the system 
retrieves a detailed transaction row (representing an individuaUzed transaction) from the 
Transaction Detail Database (901), and compares or matches data in the detailed transaction row 
with the customer criteria associated with the contract term (903). If the customer criteria is not 
met, the system retrieves the next detailed transaction row (901). If the customer criteria is met, 
however, the system or program retrieves the next contract term from the Term Definition 
Database (905). Then, the program compares the market criteria (step 907), the suppHer criteria 
(step 909), and the product criteria (step 911), which are associated with the contract term, witii 
the corresponding data from the detailed transaction row. Similarly, the program compares the 
class(es) criteria (step 913) and the distributor(s) criteria (step 915) with the corresponding data 
from the detailed transaction row. 

If the program finds a match on all of the term criteria (9 1 7), it then determines whether 
the term is a point of sale term (step 919), in which case, the system marks the transaction with 
the appropriate contract and term code (step 921). On the other hand, if the transaction is found 
to be an end-of-period transaction, the transaction is appropriately marked as such and identified 
with the contract and contract term codes (923). After either case, the system retrieves the 
discount amount from the Term Definition Database 315 (step 925). Then, the system computes 
and enters the undiscounted amoxmt for the transaction (927). 

At this point, the system inquires whether another transaction row (from the Transaction 
Detail Database) is available for marking (929). At the end of the process, all appUcable 
transactions have been marked using SQL criteria as defined and stored in the Term Definition 
Database 315. These data are unique to the invention because, among other things, these have 
been normaUzed and automatically designated by contract and term. 
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Create Transar.tinTi Slnmmar y Database 
FIGS. lOA-lOB illustrates, in simplified fonn, a process of creating a Transaction 
Summary Database utilizing the xinique transaction detail generated in the process Hlustrated by 
FIG. 5 . For a given contract term, in a first step of the process, the system retrieves pre-contract 
or historical transactions by customer identification code fi-om the Transaction Detail Database 
307 (step 1001). The system then retrieves the appropriate contract term identifier and the 
appropriate select term statements fix>m the Term Definition Database 315 (as identified by the 
term identifier) (step 1003). 

With this information, the system is then able to select transactions from the Transaction 
Detail Database which match the begirmiag and ending date of the sample (1005). Further, the 
system selects transactions by the designated distributor (1007). Using SQL criteria from the 
term definition, the system groups the transactions by market, supplier, product and class. With 
these groupings, the system computes preferred supplier(s) subtotal for transaction count, amount 
of spending, average transaction amount, and share of total business (1011). Thereafter, the 
system computes other supplier(s) subtotals for the same colunms (1015). The results of these 
computations are stored in the Transaction Summary Database 309. FIG. 20 provides an 
example of a screen illustration of a market analysis simmaary generated by the above-described 
process. 

The Transaction Summary Database from which the display module 2001 is derived is 
generated for a term entitled "US to US" as indicated in the term column 2003. The table 
displayed contains summary market rows 2003 identified by OD Pair and cabin type. These 
summary market rows 2003 have each been identified by the specified term stored in the Term 
Definition Database 315. Each market pair that qualifies for a term is grouped by Markets, 
Directional Pair, and Cabin 2005. The total count of fligjits and amount spent by all suppliers 
in the market is talUed 2007. The system then computes the flight counts, amount of spend, and 
share of flights for the designated supplier in the contract, the 'Tiost." 2009. Based on this data, 
the system can compute the variance between expected share, 'TSTAS" and Actual Share 2011. 
These summary, historical data may now be used to forecast term performance (see FIG. 11) and 
forecast contract performance (see FIG. 12). 
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Forecast Term Performaace 
FIGS. llA-llB illiistrate, in simplified form, a process of generating the Term 
Performance Database 317 for a proposed contract term. In an initial step 1101, the system 
retrieves a customer's data fi:om the Transaction Detail Database 307. Customer data fix>m the 
Market Analysis Summary which match the proposed term requurements stored as an SQL 
statement are selected (1 103). Next, purchasing totals are computed for all suppliers including 
product count, amount of spend, and average transaction price (II 05), Next, purchasing totals 
are computed for the supplier for the designated contract, the *Tiosf * supplier, including product 
coimt, amount of spend, average transaction price, undiscounted amount, and its share of the 
products purchased (1107). 

The system next retrieves the proposed term requirements for the contract term from the 
Term Definition Database. The system forecasts the customers estimated number of transactions, 
gross revenue, supplier's resulting share of business, displacement of existing non-discounted 
business, discount dilution due to lost revenue from the discount, and net profit (1109). The 
system then computes the same results without the discounted term to forecast financial results 
without the proposed deal (1111). 

Financial minimum requirements for all terms are retrieved from the Term Rule Database 
3 1 3 as previously defined in FIG 6. The forecasted results of the term are compared to the term 
rules on such criteria as minimum number of transactions, net profit, supplier share of business, 
or other financial ratios (1 115). The system informs the user whether the proposed terms meet 
the requirements of the term rules (1 1 17). If the term fails, the user may elect to revise the term 
(1 1 1 9) or over-ride the rule and accept the term, Once the term is accepted, the financial results 
of the forecast are stored in the Term Definition Database (1 123). 

A screen print of tlie results of the financial analysis of the proposed term is displayed 
in the Financial Terms tab inFIG. 21C. The term name, date range, and distributor compensation 
method are identified in the under the term column 2119. The requirement for the term, 
including payment method, requirement type and amount, and payment type and amount are 
defmed 2121. The financial projections for the term may be calculated from the Transactions 
Summary Database 309 (FIG. 10). The analysis compares results for no discount, current 
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di scount, and proposed discount 2123. The financial results are tested for minimum Profitability, 
Share, and Volume (2121) to determine if th^e meet the rules in the Term Rule Database 313. 

One advantage provided by the present system and method is that it enables suppliers to 
measure customer contract performance by user-defined periods such as by month, quarter, and 
annually. Based upon the Term Performance Database produced from data derived from the 
Transaction Detail Database, the inventive method computes an analysis that provides the period 
average, contract-to-date average, and compares these amounts with the performance 
requirement. The system then alerts the user of any non-performing term; that is, any term that 
is not meeting the requirements stated of the contract. 

Forecast Contract Performance 
FIG. 12A-12B illustrates, in simplified form, a method for forecasting contract 
performance. This is accomplished by analyzing the overall financial results of each of the 
combined individual terras. The system first retrieves the forecast results of each term from the 
Term Definition Database 315 (1201). Term totals are computed for all suppliers including 
product count, amount of spend, and average transaction price (1203). Term totals are then 
computed for the supplier for the designated contract, the "host" supplier, including product 
count, amount of spend, average transaction price, undiscounted amount, and its share of the 
products purchased (1205). 

Using the term totals, the system makes two sets of forecasts. The System forecasts the 
customer's estimated number of transactions, gross revenue, supplier's resulting share of 
business, displacement of existing non-discounted business, discount dilution due to lost revenue 
from the discount, and net profit (1207). The system also computes the same results without the 
discounted term to forecast financial results without the proposed deal (1209). 

Financial minimum requirements for the contract are retrieved from the Term Rule 
Database 313 (as previously illustrated by way of FIG 6) in step 1211. The forecasted results 
of the contract are compared to the contract rules on such criteria as minimum number of 
transactions, net profit, suppher share of business, or other financial ratios (1213). The system 
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then informs the user whether the proposed contract meets the requirements of the contract rules 
(1215). If the contract fails, the user may elect to revise the contract terms (1219) and return to 
the term definition process (see FIG. 6) or over-ride the rule and accept the contract. Once the 
term is accepted, the financial results of the forecast are stored in the Term Definition Database 
(1221). 

A screen print 220 of the results of a financial analysis of a proposed contract is displayed 
in FIG. 22. Each term is identified under a Term title column 2201 . Columns for the requirement 
for the term (2205) and measurement method (2707) are provided. Also, a financial projection 
Column 2211 is made for each term including Incremental Revenue and Percent. Detailed 
financial results and ratios are displayed for the contract in another area 2213 of the screen. The 
module also provides an indication box 2215 for the financial results of testing on minimum 
Profitability, Share, and Volume 2215 to determine if they meet the rules in the Term Rule 
Database 313. 

One advantage provided by the present system and method is that it enables suppliers to 
measure customer contract performance by user-defined periods such as by month, quarter, and 
annually. Based upon the Term Performance Database produced firom data derived firom the 
Transaction Detail Database, the inventive method computes an analysis that provides the period 
average, contract-to-date average, and compares these amounts with the performance 
requirement. The system then alerts the user of any non-performing term; that is, any term that 
is not meeting the requirements stated of the contract. 

Produce and Distribute Contracts and Terms 
The flowchart diagram in FIG. 1 3 illustrates preferred procedural steps for the production 
and distribution of performance information. The process begins with the step 1301 of gathering 
information firom the Entity Database 303 and Contact Database 305 and placing these in a 
contract shell (such as a word processor template file). The inventive system then produces a 
paper copy of the contract agreement (1303). In a subsequent step 1305, the term values are 
gathered firom the Term Definition Database 315, and then written into the contract term sheet 
(1307). A copy of the contract and terms sheet are presented to the customer who may decide 
to renegotiate agreement or accept the terms of the agreement (1309)! If the agreement is 

34 



wo 01/75745 



PCT/USOl/10798 



renegotiated, the tenn definition process begins again FIG. 8. If the agreement is accepted, the 
contracted is activated in the system (1311). 

Audit Discounted Transactions 
Supphers run the risk of distributors applying the discount from one customer to an 
imauthorized customer. The system protects against the abuse of discoxmts by auditing each 
transaction to determine if the discount has been apphed to the correct customer, discount, and 
product. The audit begins by retrieving a transaction and the code of the distributor (1401). The 
system reads the pertinent data the distributor and customer to the approved temis by contract, 
suppUer, market, product, and class (1403). The system then determines if the transaction was 
sold by the approved distributor (step 1406), to the approved customer (step 1407), for the 
correct market (step 1409), for the correct product (step 1411), with the correct discount code 
(1413), and if the discount take was correct (1415). If any of these criteria fail, the system marks 
the record with the corresponding audit number and indicates the correct term code and discount 
amount (1419). 

Measure Actual Contract Performance 
Once suppUer and customer have agreed to the contract, on-going measxirement of 
performance is critical to the success of the deal. FIGS. 15A-15B illustrate, in simpUfied form, 
how the inventive system monitors and may measure actual contract performance. The process 
begins with the detailed transactionsbeing identified and markedby customer, contract, and term 
as described in FIG. 9 (step 1 501). Performance is tracked by contract period, such as by month, 
and from contract begin date to the current date. All of a customer' is transactions are grouped 
by contract and term (1503). This collection includes transactions from the contracted supplier 
and non-contracted suppliers and provide grand totals for product counts and amoimt of spend 
(expenditure) which are essential for computing share of bxisiness (1505). The system next 
computes the customer's purchasing figures including count of products purchased, amount of 
spend, designated supplier's share of products and spend, the discounted amount for purchases, 
and the undiscounted amount which will be used to compute the amount of savings provided to 
the customer (1 507). The results of the computations are stored in summary fashion in the Term 
Performance Database 317(1 509). 
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The system next gathers the term requirements from the Tenn Definition Database 315 
(step 1511). Using those term requirements, the system tests the term requirements against the 
actual sunomary results for the term stored in the Term Performance Database 317 (step 1513). 
If the contract to date summary results indicate that the term has not met the term requirements, 
performance for the term for the period is marked as not fulfilling in the Term Performance 
Database (157). If the contract to date sxmmiary residts indicate that the term has met the term 
requirements, performance for the term for the period is marked as fiilfilling in the Term 
Performance database (1519). 

The system then gathers the contact information for the parties of the contract from the 
Entity Database 303 and Contacts Database 305 (step 1521). An electronic message, such as an 
email or fax, can then be prepared and sent to inform the parties of the contact status (1523). 

The Term Performance Database 317 is the major outcome of the above-described 
process. This summary level database may be used for quickly monitoring and evaluating term 
performance, and for the production of reports and financial analysis. 

Reconcile Final Contract Performance 
At the end of the contract, the final performance of the terms is computed. The inventive 
system and method facilitates the determination of which terms are fiilfiUed and which terms 
failed and, additionally, provides variance and financial impact. Final financial performance of 
each term may be fiirther compared to a term summary prediction model. In this way, a 
recommendation as to how fixture contracts can be improved for suppliers and customers may 
be provided. Results may also be compared to the goals stored in Sales Goal Database 19 to 
measure sales performance. Results of this analysis are distributed electronically to the contacts 
identified and recorded in the Contacts Database 305. 

FIG. 1 6 illustrates preferred procedural steps for the final reconcihation of the terms and 
contract. The process begirxs with the operator or program retrieving end of period results for 
the contract terms and the contract; from the Term Performance Database 3 17 (step 1101). Also, 
the term requirements for the particular terms are retrieved from the Term Definition Database 
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315 (step 1 1 03). The results from the Term Requirements Database and the Term Performance 
Database can now be compared. In particular, the inventive system computes the variance 
betwe^i the term results and the term requirements (1605), for such information as transaction 
count, transaction amount, percent share, gross profit and net profit. Based upon this 
comparison, the final status of the contract is then marked (1607). In this step 1607, the contract 
may be marked with the status of FULFILLED, PARTIALLY FULFILLED OR FAILED TO 
FULFILL. Next, the contract results are marked (1609) in the Sales Goal Database for the 
measurement of internal sales, and the final contract reconciliation reports are produced (1611). 
Reconciliation reports are then distributed to entities in accordance with the information from 
the Entity Database and the Contact Database (1613). 

Payout Discount 

As a contract period comes to a close, the system enables a supplier to reconcile a 
customer's performance with the contract requirements and prepare the payout of the discount. 
For example, airline customers take a discount either at the point-of-sale when a ticket is 
purchased or when the airline pays on the deal at the end of a designated temi. The inventive 
system and method provides for confirmation whether a term requirement has been met, the 
amount of discount that has been taken at the point-of-sale, or the amount that is due to the 
customer at the end of the term. FIG. 17 illustrates preferred procedural steps for this process. 

The process begins by determining whether the term is performing (1701). The system 
is able to do this by examining whether tlie term is marked in the Term Performance Database 
317 as performing or failing (see marking step 903). If the term is performing, the step 1707 of 
payment authorization is conducted. If the term in not performing, the term may be modified or 
canceled in a subsequent step 1703. The inventive method also generates payment 
documentation (1707) and records payments in a Payment Database (step 1709). Contract 
performance information is produced from the Term Performance Database 317 and is 
distributed to the contacts identified in the Contact Database 305. These reports provide the 
performance status of each term and may be distributed to both airline and customer contacts 
electronically and automatically. 
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Manage Sales Goals 

Suppliers measure the sales staff performance against predetermined goals established 
for a period (such as a year). Goals may represent the sum production of all contracts managed 
by that sales person. By totaling the summary results of the contracts assigned to a sales person, 
the inventive system determines the fulfillment status of a sales person's contracts, whether or 
not their goals have been attained, and the variance to goal. Similarly, supphers can measure 
production and contact results by region, contract type, or industry. For piuposes of example, 
FIG. 18 describes in simplified form the process used to manage sales person's goals. 

A process for providing the above begins by identifying the sales person (1801). The 
identified sales person is matched to the contracts for which he or she is responsible (1 803). The 
system then retrieves the performance results fi:om the Term Performance Database 317 (step 
1805) and retrieves the sales goals for the sales person fix>m the Sales Goal Database 319 (step 
1807), then computes the variance between actual and goal (1809). The results of this 
comparison are stored in the Sales Goal Database 319 (step 1811). Once the data have been 
stored, reports for monitoring past performance and projecting future goals are run (1813). 

Exemplary Database Tables 
FIGS . 3 and 4A-4B illustrate an exemplary set of database tables generated by the system. 
These tables are used in the software application of the inventive method for the airlines 
industry. In one application, the tables are used in analyzing a proposed contract between an 
airline (supplier entity) and its cUents (customer entity). These tables and the processes which 
employ and/or generate these tables are described in more detail below in the description of a 
software application in the airline industry. 



Table Name 


Description 


Entity Database 303 


The contracting entities including airlines, 
customers, and travel agencies. Data includes 
such elements as business name, legal name, 
and addresses. 


Contact Database 305 


The individuals responsible for the contracted 
relationship between the customer and airline. 
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Table Name 


Description 


Transaction Detail Database 307 


Detailed, normalized transactions, or flights, 
sold by the airline and purchased by the 
company as a condition of contracting. 


Transaction Summary Database 309 


Summarized data derived firom the 
Transaction Detail Database, identified by 
contract term in the Contract Registry 
Database and Term Definition Database, 
reflecting purchasing totals by contract term. 


Contract Registry Database 311 


Data associating the entities and parties in the 
contracted relationship. 


Term Rule Database 313 


The supplier-defined rules for the judging the 
minimum financial performance of terms 
including count of products, amount of spend, 
or share of business. Rules are stored using 
SQL language to test the acceptability of term 
definition. 


Term Definition Database 315 


The terms of contract including products to be 
discounted, performance measures and type, 
and discount type and amount. Terms are 
stored in SQL to be used to identify and mark 
transactions as they are loaded in the Detail 
Transaction Database. 


Term Definition Database 317 


A surrunary database that includes totals for 
flights, amount of spend, and share by 
customer. The Term Performance Database 
also tracks whether or not a term is 
performing. 


Sales Goal Database 319 


The sales goals established for the airline's 
sales persons stored as either a number of 
products, amount of spend, or share 
performance. 



The Entity Database 303 and Contact Database 305 work together to store information 
on the business entities, such as customer, airlines, or agencies, and the individuals that 
participate in contracting relationships. In an airline-contractmg environment, entities would 
include corporate customers, a contracting airline, often an airline alliance partner, and one or 
more travel agencies. Entities can change roles. For example, an agency serving as a distributor 
for one customer may also be a direct customer of the airline. This is why the database permits 
entities to change their role in any given contracting situation. Contacts are associated to the 
entities for which they work, such as a corporate customer or an airline employee. Many 
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contacts may be associated with any business entity. Contacts may also move between entities 
if their job changes. By associating contacts and entities dynamically, the system creates a 
history of the business relationship with both business entities and the contacts that work for 
them. 

Detail transaction data are derived from many sources including travel agencies, credit 
card providers, or customers. Since airUne data arrive in different fonnats, they are normalized 
into a standard origin and destination structure. For example, a two-segment flight originating 
in Albuquerque and connecting in Houston and arriving in New York La Guardia airport would 
be written as one origin and destination (ABQ-IAH-LGA). Errors that are common in airline data 
are corrected to ensure reUability. Last, the true amoxmt paid for the destinations is computed 
from the segment detail and verified with actual the actual ticket amount. These data form the 
foundation of the Transaction Detail Database 307. 

Once a contract has been estabhshed between an airline and its customer, transactions 
are marked by customer, contract, and contract term as they are loaded FIG. 9A-9C. Customer 
identification in the airline industry is particularly difficult since travel agencies that do not 
disclose their customers account numbers. The system maintains look-up tables matching 
agency account numbers to the corporate identity. Once the company has been identified, the 
system uses the Term Definition Database 315 to determine if the transaction qualifies for a 
contract. Using the structure query language description of the term, each transaction is 
processed. Where the transaction matches the temi definition, it is maiket by contract and term 
code. These new, detailed transactional data, normalized in structure and designated by contract 
and term, are the foundation of the system. 

The Transaction Detail Database includes, but is not limited to, the following data 
elements: 



Name 


Description 


Transaction Number 


The number of the transaction. 


ODl 


The first ODPair in the itinerary. 
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Name 


. Description 


OD2 


The second ODPair in the itinerary. 


Unil ' 


The first directional OD pair. 


Uni2 


The second directional OD pair. 


Carrier Code 


The mdustry standard code for the airline. 


Service Class 


The class of service flown. 


rare x3aSis v^oue 




Ticket Designator 


The unique code often put in by travel 
agents to identify a contracted fare. 


Cabin 


The plain language identification of the 
cabin type: Supersonic, First, Business, 
Economy, or Discount 


Depart Date and Time 


The departure date and time of the mght. 


Arrive Date and Time 


The arrival date and time. 


OD Amoimt 


The gross amount paid by the passenger for 
the flight, including taxes and surcharges. 


Net OD Amount 


The net amount paid by the passenger for 
the flight, excluding taxes and surcharges. 


Distance 


The point to point distance flown. 


Elapsed Minutes 


The point to point time for the flight. 


Cross Boarder 


Identifies transactions that contain flights 
that cross country boarders. 


Company E) 


The unique number given to designate the 
customer 


Contract ID 


The umque number given to designate the 
contract. 


Term ID 


The unique number given to designate the 
Term of the contract. 


Discount 


The amount of discount appUed to the 
transaction. 



The Transaction Summary Database 309 contains summary transaction data derived from 
the Transaction Detail Database above. Summary data are grouped by market, cabin, and class 
of service and are used for an analysis performed for a contract (i.e., used in qualifying or 
otherwise analyzing the performance of a contract). In this particular application, there is one 
market analysis per contract and thus one set of definitions for each contract. The table includes 
columns for the contract ID, the analysis begin date, the analysis end date, and the top number 
of miarkets which are included in the analysis. The supplier often limits the contract analysis to 
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certain of the customer's markets or top markets. Sometimes, only these top markets are used 
in the analysis. Specific discounts are determined for these top markets while a general discount 
is applied to all other markets. . 

A Transaction Stunmary Database contains a summary of origin and destination rows 
which are those detailed transactions appUcable to or identified with the proposed contract (see 
e.g. FIG. 20). After the top number of markets for a cxistomer is identified, this table is generated 
for those markets. Among other information, this table contains rows of OD Pairs and 
Directional Pairs and includes the number of flights, amount, and share of flights for the 
designated carrier or aUiance and other carriers. With this data available, terms may be applied 
to groups of markets and a forecast can be made using the proposed terms and to judge the 
financial results of the contract. 

Other colunms of information provided in Transaction Summary Database include sums 
or totals for all ODs for the company of the contract and in the date range of the market analysis. 
Information includes sum of the net OD accounts (system flights), sum of the OD amount 
(system amount), sum of the net OD count for ODs flown by the contracting carrier or carriers, 
sum of the undiscoimted OD amounts, amount paid out in back end discoimts, and firont end and 
back end carrying costs and dilution costs. Other columns of information include market share, 
weighted average manage share, commission percentage, override percentage, carrying costs, 
high and low fares, and other financial information. 

The Data Transaction Summary Database includes, but is not limited to, the following 
data elements: 



Name 


Description 


ODl 


The ODPairl that this result is computed 
for. 


0D2 


The 0DPair2 that this result is computed 
for. 


Unil 


The UniPairl that this result is computed 
for 
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Name 


Description 


Uni2 


The UniPairZ that this result is computed 
for 


Cabin ID 


The ID of the cabin type that this result is 
computed for 


Service Class 


The class of service that this result is 
computed for 


Front End Term ID 


The tenn ID assigned if the row meets the 
requirement or discount query criteria for a 
front end (time of ticketing) term. Once a 
term ID is assigned, it cannot be overwritten 
by a subsequently defined tenn. If the term 
ID is zero, then no term is assigned. 


Front End is Discoimted 


Flag determining whether the discount 
criteria or the requirement criteria for the 
front end contract temi is met. 


Back End Term ID 


The term ID assigned if the rule meets the 
requirement or discount query criteria for a 
back end term. 


Back End is Discounted 


Flag determining whether the row meets the 
discount criteria or the requirement criteria 
for the back end contract term. 


Market Type Code 


The imique, user-defined code that enables 
suppliers to group markets for the purpose 
of analysis. 



Thus, the Transaction Summary Database provides a collection of transactions (ODs) 
applicable to a current or proposed contract and its contract terms. The table also includes all the 
pertinent attributes of those transactions. Using some of these attributes as input, the 
performance of the proposed or current contract may be analyzed and various performance 
reports generated, FIG. 19 depicts a software display module 1901 providing some the 
information in the Market Analysis Summary table. 

The Contract Registry Database 311 contains information on all the contracts between 
the suppUer and its customers. The Contract Registry Database includes, but is not limited to, 
the following data elements. 
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Column Name 


Description 


Contract ID 


The unique system generated ID for the 
contract. 


Company ID 


ID identifying the company to which the 
contract applies. 


Contract Type ID 


ID of the contract type, e.g., agency, agency 
cluster, alhance, corporate, corporate 
cluster, and meeting. 


Contract Status ID 


^.g., active, canceled, pending. 


Contract Begin Date 


Beginning date for a vaUd contract. 


Contract End Date 


End date for a valid contract. 



Thus, given a contract ID, the company, contract type, status, and begin and end dates may be 
associated the Contract table. 

Airlines often permit field sales persons to define their own contract terms. When this 
occurs, contracting officers require a means to ensure that the deal falls within acceptable 
parameters. The application establishes these parameters within the Term Rule Database 311. 
Rules may be estabUshed for any financial or performance criteria measured in the data. For 
example, performance may be measured by a required total number of flights within a market, 
or by arequired amount of expenditure, or arequired share of business. Performance ratios may 
also be entered, such as profitability, dilution, or fair market share. As terms are modeled using 
historical data summarized in the Transaction Summary Database, rales from the Term Rule 
Database are appUed. Users are notified when the parameters of any term fail the test of a rule. 

The Term Definition Database 315 also includes colimms which identify whether the 
contract is net of commission, net of override, and/or a net of credit card commission. Whenever 
any of these flags are triggered during a contract analysis, a payment or deduction to a transaction 
amount (or contract amount) is usually effected thereby decreasing the totals for that contract. 
The database also contains information of the payout schedule table for back end contract terms. 
Back end deals may be paid out incrementally throughout the contract. The columns in this 
database table include contract ID, contract term ID, payment date, pay period start ^date, 
requirement achieved for the pay period, actual discount percentage paid for the period, and 
payment amount. Where back-end payouts are based upon performance steps, the Term 
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DeJBmtion Database contains data these steps for back end contract terms. Back end deals may 
pay different amoimts based on the share that is received. This database includes columns for 
contract ID, contract term ID, step requirement, and step discount. Note that the step requirement 
of value may be a percentage, account or dollar amount, depending on the requirement measure 
ID of the term. Similarly, the step discoimt may be a percent or amoimt of discount per ticket 
for this step. The Data Definition Database includes, but is not limited to, the following data 
elements. 



Column Name 


Description 


Contract ID 


System generated unique ED for this 
particular contract. 


Contract iermiD 


System generated unique ID for this 
particular term of contract. 


Term Begin Date 


Starting Date for which this particular term 
is effective. This date is used when 
marketing ODs. 


Term End Date 


The ending date that this term is effective. 
This date is sued when marketing ODs. 


Discount Type ID 


The ID of the discount type for this term, 
e.g., front end (time of ticketing) or back 
end. 


Discoimt Measure ID 


The unique ID for this measure, e.g., by 
amount, no discount, one-way base fare, or 
percent. 


Discount 


Percent or amount of discount per ticket for 
this term. 


Requirement Measure ID 


The ID of the measure for this term, e.g., by 
amount, flight, no requirement, share of 
amounts, or share of flights. 


Requirement 


The requirement value for this term. This 
value may be a percentage, a count or dollar 
amount, depending on the measure ID. 


Query ID 


The ID of the criteria for the query which 
defines the OD rows which count towards 
the requirement of the contract term. The 
corresponding SQL is stored in the term 
definition database. These rows are marked 
with the contract term ID. 
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Financial Query ID 



The ID of the criteria for the query which 
defines OD rows to receive the discount of 
the contract term. This query is stored in 
the Term Definition Database. These rows 
are marked with the contract term ID. 



Upon the implementation of a contract, transactions are marked by company, contract, 
and term in the Transaction Detail Database. From these data, a summary database is created, the 
Term Performance Database 317, that is used to monitor the performance of contracts. Grouping 
the data by term within periods, the system compiles totals required for the measurement of 
contract performance. These data include total flights, total amount of spend for all carriers. Total 
fhghts, amount, share, discounted and undiscoimted amounts are then determined for the 
contracted carrier. Comparing these totals to the requirements stored in the Term Definition 
Database, the system determines whether or not the term or contract is fulfilling. The data 
elements in the Term Performance Database includes, but is not limited to, the following data 
elements. 



Column Name 


Description 


Contract ID 


System generated unique ID for this 
particular contract. 


Contract Term ID 


System generated unique ID for this 
particular term of contract. 


Contract Period 


Measurement period within the contract, 
such as a month or quarter. 


System Flights 


Total number of flights for all suppliers that 
meet the term criteria. 


System Amount 


Total nmnber of spend for all suppliers that 
meet the term criteria. 


Host Flights 


Total number of flights for the host supplier 
that meet the term criteria. 


Host Amount 


Total for the host suppliers that meet the 
term criteria. 


Host Flights Share 


Share of host flight of total flights. 


Host Flight Amount 


Share of host flights amount. 


Status 


Status of contract performance for the 
period; that is, whether the contract is 
fulfilling or not fulfilling. 
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The Sales Goal Database 319 stores sales goals for an airline's sales stafiF. These goals 
may be expressed as a number of flights, amount of spend, or share of business, or any 
combination of these. Companies are assigned to sales persons to manage contracted 
relationships. At the end of a performance period, the actual production of the contracts is 
compared to the sales-person's goals to measure performance. Since sales goals are stored for 
any period, performance may be measured year over year or projected for an upcoming year. 

While these nine tables server as the foundation of the inventive system, other tables are 
required for look-ups, indexes, and scheduling. All data are linked to provide an application for 
the comprehensive management of contracted relationships. An example of an airline application 
follows. 



More on Exemplary Airline Application 
The present description now provides more specific examples of applications of various 
portions of the inventive system and method in the airlines industry is provided. The various 
processes are implemented by a system and software operable by an operator-employee of the 
airline carrier or a distributor, and used to analyze proposed and current contracts and to generate 
reports therefor. The software application preferably includes several modules which are 
user-interactive to generate and analyze proposed contract and terms. FIGS. 19 - 22 provide 
screen shot examples of these. 

FIG. 1 9 . provides an illustration of a normalized detailed transaction 1901. All of the data 
provided must be constructed from multiple data sources including travel agency invoice data 
and airline segment data. Ticket level data are typically constructed primarily from travel agency 
invoice data 1903. This data also provides the information to identify the customer 1905. While 
customers may have many agency account numbers, the system groups these many accounts into 
one, discrete customer number. One number is essential for purposes of mapping a customer to 
a designated contract. The bottom half of the record includes an example of one origin and 
destination 1907. These data are derived from airline segment data. Segments are the individual 
flights a passenger flies to reach a destination. In the example, the passenger departs from 
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Albuquerque, connects in Houston, and airives in Atlanta, While the passenger flew two 
segments, he actually bought one origin and destination, ABQ-HOU-ATL. Nonnahzed data in 
the origin and destination data format is essential because it reflects the product the customer 
bought under the contracted relationship FIG 7A - 7C. . Once data that identifies the product has 
been created, the data may be tested to determine if it qualifies for a contracted discount. Using 
SQL criteria stored in the Term Definition Database 315, each origin and destination loaded into 
the system is tested to see if it quaUfies for a term. If it does, the transaction is marked by 
contract and term 1909, as described in the data marking procedure FIG. 9A - 9C. Last, the 
system determines the true origin and destination value by assessing, and if needed correcting, 
the segment amounts to ensure that the segments and all other charges equal the full ticket 
amount. This step provides the true origm and destination cost 1911 which is essential to 
detemodne the amoimt of discount. 

FIG. 20 provides an illustration of the Market Analysis Sununary module 2001. Prior 
to developing the terms of a contract, the user polls the Transaction Detail Database 3 1 to create 
a Market Analysis Summary table. These data include a colunrn in which the term name will be 
applied (2003), the Market (2005), the total Fhghts and Amoimt for all carriers in the market 
(2007), the Host's Flights and Amount (2009), and the Host's share of businesses (2011). As 
terms are constructed, terms are applied to the Market Analysis Summary, and the Term name 
is written into the Term name column. Terms are individually added until all markets that the 
airline wants to discount are conmiitted. Data firom the Market Analysis Summary is used to 
forecast the financial performance of the term. 

In an airline industry software application, the inventive system and method enables the 
user to define individual contract temis which provide for discounts to be paid for tickets booked 
to specified destinations. The definition of individual contract terms is perfomaed in the Term 
Definition Module of the software (see FIG. 2 1 A-2 1 C) . The system process is described in detail 
in FIG. 8A" 81. 

From a list of term criteria, fte user or operator first selects the criteria for the Discount 
2103. By selecting market and cabin criteria, the system displays the appropriate form for the 
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user to 1511 in the discount requirements 2105. Each term comprises different combinations or 
carriers, markets, and cabin. The results of the discount requirements are displayed in plain 
language in the Term column 2107. The system then converts the criteria into a structured query 
language format stored in the Term Definition Database 315 that is used by the computer for 
identifying and marking flights that apply to the term. The discount requirements are stored as 
SQL statements that will be applied to the historical data stored in the Transaction Summary 
Database 309 to forecast the term's financial performance, and to mark new transactions loaded 
into the Transaction Detail Database, as they are loaded into the system. The use of the computer 
to identify these terms eliminates the reqxiirement for manual input of unique supplier codes and 
also enables the matching of the term for other carriers. 

In a next stage, the user defines the Measure-on 2109 requirements, or what the custonier 
is expected to produce for the discount defined above. In consideration of these commitments, 
the airline agrees to pay a discount. In the inventive method, the user defines the discoxmt as a 
percent off of the actual fare, a monetary discount per ticket, or a designated flat fare. Discounts 
to be paid to the customer are also defined by way of the Term Definition Module. By selecting 
the form of payment, either at the point of sale or end of contract period, the user may then define 
the type and amoxmt of discount and performance requirement. At the completion of the 
Measure-on screen, the results are stored as SQL statements in the Term Definition Database 
315. 

In a subsequent stage, the user selects the financial requirements of the term. FIG. 21 C 
depicts the Term Definition Mode 21 19 and the Financial Requirements selection mode 2121. 
Selection windows provide for selection of the various term attributes, including term period, 
agency compensation, and discount parameters. A forecast of the term's perforaiance is 
displayed in window 2125. The process is described in detail m FIG. 11 A - UB. Once the 
financial forecast is complete, a box 2123 displays alerts if the term falls below the required 
minimums established in the Temi Rule Database 313 as described in FI.G. 6. By modifying 
requirements for share and levels of discount, the operator can adjust the fiaiancial performance 
of the term until it satisfies the Term Rule requirements. 
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Once the individual terms have been defined, the system produces a financial forecast of 
the contract in its entirety in the Contract Performance screen 2201 . Each term is identified by 
name 2203, requirement2205, method of paformance measurement 2207, and the discount to 
be provided 2209. Based upon the financial results stored for each term in the Term Definition 
Database 315, the system forecasts the incremental revenue above current revenue for the term 
22 1 1 and its percentage. Ratios judge the financial benefit of the term include profit/dilution and 
fair share ratio. The system displays a forecast for the overall financial performance of the 
contract includingNo Deal Revenue, Current Revenue, and ProposedNewRevenue.Based upon 
these figures, the system calculates the Net Profit of the deal 22 1 3 . The overall worthiness of the 
contract is tested with criteria established in the Term Rule Database 2215. Where profitability, 
share, or volume fails a test, the system displays an alert. Based upon actual, normalized data, 
the system has provided a forecast of the financial performance of each term and the overall 
contract. 

After the contract has been implemented, the inventive system uses data from the 
Transaction Detail Database 307 to construct the Term Performance Database 317 described in 
step FIG. 1 5 A - 1 5B . The operator my run reports that display the actual financial performance 
of a contract at any time during or after the contract period 2301. The report displays by 
Company, Contract, and term the financial results of the contract 2303. The Host Flights and 
Market Share columns reveal the number of flights and the Host's share of the total flights 2305; 
the Host Net Amount and Market Share reveal how much has been spent and the Host's share 
of the total expense 2307. The Measure column describes the method of measuring the 
customer's performance and the requirement 231 L The actual performance compared to the 
requirement provides the percentage Variance between actual and requirement 23 1 3 . B ased upon 
these results, the system determines whether or not the term has been fixlfilled or not with a "y^s" 
or "no" designation 2315. 

The overall results of the contract may also be assessed using the sum of the term 
requirements. The Minimum flights amount is computed and compared to the actual Contract 
Performance 23 17. The variance between the two described by flights displays the overage or 
underage of performance 2319. Likewise, the difference between the minimum amount and 
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actual amount displays the variance by amount. In the final analysis, using the variance of flights 
and amount, the system deteraaines whether or not the contract is fulfilling 2323. 

The foregoing description is presented for purposes of illustration and is not intended to 
limit the invention to the forms disclosed herein. Although the description is primarily directed 
to an application of the inventive system and method to the airline industry, the system and 
method may be employed in other common carrier applications and in other industries. For 
example, the system and method may be adapted for application in other volume buying 
contractual relationships and with respect to other services and/or products (e.g., purchase of raw 
construction materials or utilities). Variations and modifications commensurate with the above 
teachings, and the skill or knowledge of the relevant art, are within the scope of the invention. 
The embodiments described herein are further intended to explain the best mode loiown for 
practicing the invention (i.e., as applied to the carrier industry) and to enable others skilled in the 
art to utilize the invention in such, or other, embodiments and with various modifications 
required by the particular applications or uses of the present invention. It is intended that the 
claims be construed to include alternative embodiments to the extent that is peraaitted by prior 
art and within the spirit of the invention. 
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What is claimed is: 

1. A method of managing purchasing contracts between supplier entities and 
customer entities for the purchase of products, said method comprising the steps of : 

generating at least one purchasing contract between at least one supplier entity and at 
least one customer entity, the purchasing contract being applicable to one or more contracted 
purchasing transactions effected, at least partially, through a computerized system, said 
generating step including 

defining one or more contract terms, each contract term having one or more term 

attributes, and 

storing a term data set of the terai attributes associated with each contract term 
in one or more computer databases; 

collecting sets of transaction data relating to one or more purchasing transactions; 

storing the transaction data sets in one or more computer databases; 

identifying one or more sets of transaction data as a contract transaction data set for a 
contract transaction identifiable with a contract term; 

and 

generating a collection of contract transaction data sets by associating the transaction data 
set of each identified contract transaction with each term data set of a contract term with which 
the transaction is identified. 

2. The method of claim 1, further comprising the step of executing a computer 
program to measure the performance of a contract term, whereby the computer program inputs 
data from one more of the contract transaction data sets associated with the contract term. 

3. The method of claim 1, further comprising the step of executing a computer 
program to identify one or more of the purchasing transactions as a contract transaction by 
selecting at least a portion of the transaction data for a purchasing transaction and comparing the 
selected portion with the term attributes set for a contract term, whereby the transaction is 
identified as a contract transaction when the selected portion is identified with one or more of the 
term attributes. 
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4. The method of claim 3, wherein the supplier entity and the customer entity have, 
associated therewith, one or more entity attributes, said method further comprising the steps of: 

specifying one or more entity data representing each of the entity attributes or a 
combination thereof; and 

including the entity data in each term data set such that the contract transaction data set 
includes entity data. 

5 . The method of claim 4, wherein the specifying step includes specifying entity data 
representing an entity attribute from the group of entity attributes consisting of: customer entity 
organization information, designated customer employee contact information, supplier entity 
organization information, designated supplier employee contact information, and combinations 
thereof. 

6. The method of claim 3, wherein the step of storing a term data set for each 
contract term includes selecting one or more term attributes from the group of term attributes 
consisting of: supplier entity identifiers, customer entity identifiers, contract identifiers, contract 
term identifiers, term performance rules, term discount, term requirements, and combinations 
thereof. 

7. The method of claim 3, further comprising the steps of: 

for each contract, specifying entity data including supplier entity data designating one or 
more individuals associated with the contract for the supplier entity, and customer entity data 
designating one or more individuals associated with the contract for the customer entity; and 

associating the entity data with each of the contract temas for the contract such that the 
contract transaction data sets generated include the entity data. 

8. The method of claim 3, wherein the step of generating a collection of contract 
transaction data sets includes generating a contract transaction data set including a suppher entity 
identifier, a customer entity identifier, a contract identifier, and a contract term identifier. 
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9. The method of claim 3, wherein the step of collecting transaction data includes, 
receiving, at one or more cUent stations, transaction data relating to a partial purchase 

transaction, wherein the partial purchase transaction OTibodies less than a whole portion of a 
predetermined individualized transaction for a product; 

deriving an individualized transaction from one or more partial purchasing transactions, 
the individualized transactions being associated with an individualized transaction data set; and 

storing the transaction data set for the individuaUzed transaction in one or more computer 
databases. 

10. The method of claim 3, wherein the contract generating step includes: 
collecting historical transaction data sets representing purchasing transactions by the 

customer entity; 

identifying a proposed contract term having a set of one or more term attributes; 

identifying historical transaction data sets applicable to the proposed contract term by 
comparing contract term attributes with at least a portion of each historical transaction data set; 

qualifying one or more contract terms by, forecasting the performance of the proposed 
contract term using, as input, at least a portion of each identified historical transaction data set, 
and qualifying the proposed contract term based, at least partly, on the forecasted performance; 

assigning the contract term to a proposed contract; and 

evaluating the proposed contract with one or more of qualified contract terms. 

1 1 . Tlie method of claim 1 0, wherein the step of collecting historical transaction data 
includes collecting historical transaction data from a plurality of distinct sources. 

12. The method of claim 10, wherein the step of collecting historical transaction data 
includes collecting historical transaction data in a pluraUty of data formats and converting each 
of the collected transaction data into historical transaction data sets in accordance with a common 
format. 
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1 3 . The method of claim 1 0, wherein the step of qualifying a proposed contract term 
includes designating the proposed contract term as qualified if the forecasted performance 
satisfies a predetermined performance criteria. 

14. The method of claim 13, fiirther comprising the step of storing a plurality of 
proposed contract terms including one or more term performance rules for each proposed term, 
wherein the step of qualifying a proposed contract term includes comparing the forecasted 
performance with a term performance rule. 

15. The method of claim 1, wherein the step of collecting transaction data includes 
receiving transaction data in a pluralify of data formats and storing the received transaction data 
in accordance with a conraion format. 

1 6 . The method of claim 1 5, wherein the step of storing received data includes storing 
data representing transaction attributes from the group of transaction attributes consisting of 
coxmt of product units, cost of product, product code, customer entity code, suppUer entity code 
including product originator and product distributor, and combinations thereof 

17. The method of claim 1 , wherein the step of collecting transaction data includes, 
providing an ancillary database containing data representing product attributes of each 

of a suppUer's products, whereby individual transaction for a single product are identifiable with 
one or more product attributes; 

receiving, at a client station, parent transaction data relating to a parent purchase 
transaction, wherein the parent transaction embodies one or more individuahzed transactions; 

deriving one or more individualized transactions from the parent transaction by executing 
a computer program to compare at least a portion of each parent transaction data Avith the product 
attributes stored in the ancillary database; 

defining an individualized transaction with each of the identified products, each of the 
individuahzed transactions being associated with one or more of the transaction data set; and 

storing each transaction data set for each individualized transaction in one or more 
computer databases. 
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18. The method of claim 1, wherein the step of identifying one or more of the 
contracted transactions includes electronically marking each identified transaction data set with 
a unique contract term code and one or more entity codes specifying one or more of the suppher 
entity and the customer entity. 

19. The method of claim 18, wherein the step of defining a contract tenn includes 
storing an SQL statement that describes each term and wherein the marking step includes 
generating an SQL statement to match transaction data sets with a contract temi. 

20. The method of claim 1, further comprising the steps of: 

generating a transaction database for storing the collected transaction data sets in a 
common format; 

generating a term database for storing the contract term attributes sets; 
generating an entity database for storing data relating to suppher entities and customer 
entities; 

generating an entity contacts database for storing data relating to information on 
individuals designated to a contract at supplier entities and individuals designated to a contract 
at customer entities; and 

generating a term performance database for storing measured term performance data; 

whereby each of the databases are computer databases interconnected to one or more data 
processing means. 

21. In a method of managing purchasing contracts between at least one suppher entity 
and at least one customer entity, wherein the purchasing contract is apphcable to one or more 
contracted purchasing transactions for products eflfected, at least partially, through a 
computerized system, a method of generating a purchase contract, said method comprising the 
steps of: 

collecting transaction data relating to historical purchasing transactions by the customer 

entity; 

storing, in one or more databases, a set of transaction data for each historical purchasing 
transaction; 
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dejBning one or more proposed cxnitract terms; 

defining one or more term attributes associated with each proposed contract temi and 
storing the term attributes as a term data set in one or more databases; 

executing a computer program to qualify each proposed contract term, including 
selecting one or more of the stored term attributes; 

identifying each transaction data set that satisfies the selected term attributes; 
forecasting a performance result of the proposed contract term using, as input, at 
least a portion of each transaction data set identified; and 

qualifying the proposed contract term if the forecasted result satisfies a 
predetermined performance criteria; and 

assigning a purchasing contract between the supplier entity and the customer entity, fhe 
purchasing contract having one or more qualified contract terms. 

22. The method of claim 2 1 , fiirther comprising the step of defining one or more term 
performance rules for each proposed contract term and storing the performance rules in one or 
more databases, and wherein the step of qualifying the proposed contract term includes 
comparing the forecasted performance result with one or more performance rules associated with 
the contract term, whereby the performance rules provide the predetermined criteria, 

23 . The method of claim 21 , wherein the step of collecting transaction data includes 
receiving transaction data in a plurality of data formats and selecting a predetermined portion of 
each collected transaction data for the storing step. 

24. The method of claim 23, wherein the step of storing transaction data sets include 
storing each of the transaction data sets in accordance with a cormnon format. 

25 . The method of claim 22, fiutiier comprising the step of individuaU2dng each of 
the collected transaction data, including executing data processing means to convert each 
transaction data set to one or more individualized transaction data sets, whereby each 
individualized transaction data set is associated with a single predetermined product, 

26. The method of claim 25, wherein the step of collecting transaction data sets includes, 
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providing an ancillary database containing data representing product attributes of each 
product, whereby individualized transactions for a single product are identifiable with one or 
more product attributes; 

receiving, at a client station, infonnation relating to a parent purchase transaction, 
wherein the parent transaction embodies one or more purchasing transactions; and 

deriving one or more individualized transactions &om the parent transaction by executing 
data processing means, including 

selecting at least a portion of data collected for the parent transaction, 
comparing the selected data with the product attributes stored in the ancillary 
database to identify one or more products, and 

defining an individualized transaction with each of the identified products, each 
of the individuaUzed transactions being associated with one or more of the transaction data set. 

27. The method of claim 21, wherein the step of identifying transaction data sets 
includes electronically marking each identified transaction data set with a unique code associated 
with the contract term. 

28. The method of claim 27, wherein the marking step includes marking the 
transaction data set with a contract code and one or more entity codes specifying one or more of 
the supplier entify and the customer entity. 

29. The method of claim 27, wherein the step of defining a contract term includes 
storing an SQL statement that describes each term and wherein the marldng step includes 
generating an SQL statement to match transaction data sets with a contract term. 

30. The method of claim 21, wherein the step of storing transaction data includes 
creating a common format characterized by a single line of transaction data, and wherein the 
transaction data set represent infonnation selected firom the group of historical purchasing 
information consisting of: product description, count, cost, date, time, salesperson, computed 
share applicable to supplier entity, and combinations thereof 
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31. A method of managing a purchasing contract between at least one supplier entity 
and at least one customer ratity, said method comprising the steps of : 

generating a purchasing contract between at least one suppUer entity and at least one 
customer entity, the purchasing contract being q)plicable to one or more contracted purchasing 
transactions effected, at least partially, through a computerized system, said generating step 
including 

identifying one ormore contract attributes associated with the contract, including 
one or more contract terms, each contract term having associated therewith a measurable 
performance parameter wherein the value of the performance parameter is dependent, at least in 
part, on the occurrence of one or more contracted transactions, and 

storing the contract attributes including the contract terms in one or more 

databases; 

collecting transaction data relating to one or more purchasing transactions, the collected 
transaction data including data representing one or more transaction attributes associated with 
each purchasing transaction; 

executing a computer program to identify one or more of the purchasing transactions as 
a contract transaction by selecting one or more of the transaction attributes and comparing the 
selected attributes with the contract attributes, whereby a contract transaction is identified when 
a predetermined one or more qf the selected attributes are identifiable with one or more of the 
contract attributes; and 

executing a computer program to measure the performance of a contract term using, as 
input data, transaction attributes of one or more contract transactions. 

32. The method of claim 31, further comprising, after the step of collecting 
transaction data, the steps of: 

storing the collected transaction data for each transaction as a transaction data set; and 
storing the transaction data sets in a transaction database in accordance with a common 
format; and 

wherein the step of executing a computer program to identify contracted transactions, 
includes accessing the transaction database. 
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33. The method of claim 31, further comprising the step of providing a term 
performance rule for detennining the fulfilbnent of each contract term, and storing the term rule 
in one or more computer databases, and wherein the step of executing a program to measure 
contract term performance includes generating a current term performance value and comparing 
the performance value with a term performance rule. 



34. The method of claim 31, wherein the step of storing collected transaction data 
includes selecting data representing one or more transaction attributes selected from the group 
of transaction attributes consisting of: product code, product cost, transaction time, transaction 
date, seller identifier, computed share, and combinations thereof 



3 5 . The method of claim 3 1 , further comprising the steps of: 

providing an ancillary database containing data representing product attributes of each 
of a supplier's products, whereby an individualized transaction for each product is identifiable 
by one or more product attributes; 

receiving, at a cUent station, parent transaction data relating to a parent purchase 
transaction, wherein the parent transaction embodies one or more individualized transactions; 

executing a computer program to compare at least a portion of each parent transaction 
data with product attributes stored in the ancillary database so as to identify one or more 
products; 

defining an individualized transaction with each of the identified products, each of the 
individualized transactions being associated with one or more of the transaction data set; and 

storing each transaction data set for each individualized transaction in one or more 
computer databases. 

36. The method of claim 31, wherein the step of identifying one or more contract 
attributes includes selecting, for the storing step, one or more contract term attributes from the 
group of term attributes consisting of: term discount, term discount method, term date range, 
term performance rules, term identifier, authorized distributors, distributor commission, and 
combinations thereof 
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37. The method of claim 31, further comprising the steps of: 
defining a contract term identifier for each contract term; and 

for each identified contracted transaction, associating the transaction data set with the 
contract term identifier with which the contract transaction is identified, whereby the associated 
transaction data set and the contract term identifier constitute a contract transaction data set. 

38. The method of claim 37, wherein the step of executing a computer program to 
measure contract term performance includes using, as input, data fi-om accessing each of the 
contracted transaction data sets associated with the contract term. 



39. The method of claim 38, wherein the step of measuring the perfonnance of the 
contract term includes selecting, for the measuring step, a performance value firom the group of 
perfonnance values consisting of: total product count, total cost, supplier share, unit cost, and 
combinations thereof; and 

wherein the step of storing contract attributes includes storing a set of contract term 
attributes for each contract term, and wherein each of the at least one supplier entity and the at 
least one customer entity have, associated therewith, one or more entity attributes, said method 
further comprising the steps of: 

specifying one or more entity data representing each of the entity attributes or a 
combination thereof; and 

including the entity data in each term attributes set such that the contract transaction data 
set includes entity data. 

40. A method of managing a purchasing contract between a suppHer entity for a 
common carrier and a customer entity, the contract being applicable to one or more 
contracted ticketing transactions, each of the ticketing transactions being associated with a 
ticket unit, said method comprising the steps of: 

generating a purchasing contract between at least one suppHer entity and one customer 
entity, including identifying one or more contract terms, each contract term havmg one or more 
term attributes, and storing the term attributes associated with each contract term as a term data 
set in one or more computer databases; 
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collecting transaction data for one or more ticketing transactions from a plurality of data 
sources; 

storing a set of transaction data for each ticketing transaction in one or more computer 
databases and in accordance with a common format; 

executing a computer program to identify one or more of the ticketing transactions as a 
contracted ticketing transaction by selecting at least a portion of the transaction data set for a 
transaction and comparing the selected portion with the term data set for a contract term, 
whereby the transaction is identified as a contracted ticketing transaction upon identifying the 
selected portion with a portion of the term data set; and 

electronically marking each identified transaction data set with a unique code associated 
with the contract term; and 

executing a computer program to measure the performance of the contract term using, as 
input, at least a portion of the transaction data set for each identified contracted ticketing 
transaction. 

4 1 . The method of claim 40, fiuifaer comprising the steps of: 

providing an ancillary database containing data representing product attributes of each 

ticket unit, whereby individual ticket units are identifiable by one or more product attributes; 
receiving, at a cUent station, information relating to a parent purchase transaction 

including a transaction data set, wherein the parent transaction embodies one or more ticketing 

transactions; and 

deriving one or more individualized ticketiag transactions from the parent transaction by 
executing data processing means, including 

selecting one or more of the transaction attributes, 

comparing the selected transaction attributes with the product attributes stored in 
the products database to identify one or more ticket units; and 

defining an individuaUzed ticketing transaction with each of the identified 
ticketing units, each of the individualized ticketing transactions being associated with at least 
portion of the collected transaction data set; 

wherein the step of storing transaction data includes storing a transaction data set for each 
of the individualized ticketing transaction. 
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42, The method of claim 40, further comprising the step of generating a collection of 
contracted ticketing transaction data sets by associating the transaction data of each identified 
contracted transaction with each term data set with which the transaction is identified; and 

wherein the step of measxiring the performance of a contract term includes accessing the 
contracted transaction data sets, whereby the computer program inputs data from one or more 
of the identified ticketing transaction data sets associated with the contract term. 



43 . The method of claim 42, fiirther comprising the steps of: 

storing, in one or more computer databases, entity data relating to each of the supplier 
entity and the customer entity, including entity data representing an entity attribute from the 
group of entity attributes consisting of: customer entity organization information, designated 
customer employee contact information, supplier entity organization information, designated 
suppUer employee contact information, and combinations thereof; and 

associating the entity data with tiie transaction data set of each identified contracted 
ticketing transaction, such that the contracted ticketing transaction data set generated includes 
entity data. 

44. The method of claim 43, wherein the step of storing a term data set for each 
contract term includes selecting one or more term attributes from the group of term attributes 
consistingof: suppUer entity identifiers, a customer entity identifier, contract identifiers, contract 
term identifiers, term performance rules, term discount, term requirements, and combinations 
thereof; and 

storing data representing the selected term attributes in the term data set. 



45. The method of claim 40, wherein the step of storing transaction data includes 
storing at least data representing attributes from the group of transaction attributes consisting of: 
count of product units, cost of product, product code, customer entity code, supplier entity code 
including product originator and product distributor, and combmations thereof 

46. In a system for managing a purchasing contract between at least one suppUer 
entity and at least one customer entity, the contract being applicable to a plurality of contract 
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transactions effected, at least partially, through a computerized system, a computerized method 
for creating contract transaction data sets usable with the system, said method comprising the 
steps of: 

defining a contract having one or more contract terms, each of the contract terms having 
a set of term attributes associated therewith, including a criteria for identifying transactions 
applicable to the contract term; 

storing each of the sets of term attributes as a term data set in one or more databases; 

collecting transaction data sets, each transaction data set relating to a purchasing 
transaction, and storing the transaction data set for each purchasing transaction in one or more 
databases; 

executing a computer program to identify one or more of the purchase transactions with 
one or more contract terms by selecting at least a portion of the transaction data set associated 
with each purchase transaction and comp aring the selected portion of the transaction data set with 
at least a portion of the term data set associated with the contract term, whereby a contract 
transaction is identified when a predetermined portion of the selected transaction data set is 
identified Avith the portion of the term data set; and 

associating at least a portion of the term data set with each identified transaction data set 
to generate a collection of contract transaction data sets. 

47. The method of claim 46, further comprising the steps of: 

identifying at least one customer entity and at least one suppUer entity, each of the entities 
having one or more distinct entity attributes; 

specifying entity data representing each of the entity attributes or combinations thereof; 

and 

storing the entity data with each stored term data set; 

wherein the step of specifying entity data includes specifying data identifying one or 
more individuals associated with the contract for the supplier entity and one or more individuals 
associated with the contract for the customer entity. 

48. The method of claim 47, wherein the step of associating each identified 
transaction data set includes marking each identified data set with a contract identifier and a 
contract term identifier. 
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49. The method of claim 47, wherein the step of associating each identified 
transaction data set includes generating an SQL statement to match the transaction data set with 
at least portion of the term data set. 

50. The method of claim 47, wherein the step of collecting transaction data sets 
includes collecting data sets in a plurality of data formats and from a plurality of sources, and 
wherein the step of storing the transaction data sets includes storing the transaction data sets in 
accordance with a common format. 

51. The method of claim 50, wherein the step of storing transaction data includes 
storing data representing transaction attributes selected from the group transaction attributes 
consisting of: count of product units, cost of product, product code, customer entity code, 
supplier entity code including product originator and product distributor, and combinations 
thereof; 

whereby the contract transaction data sets generated each include the selected data. 

52. A computerized system foruse inmauaging apurchasing contract between at least 
one supplier entity and at least one customer entity, the contract covering aplurality of contracted 
transactions effected, at least partially, through acomputerized system, said system comprising: 

one or more data storage systems storing (i) entity data specific to the suppher entity and 
entity data specific to the customer entity, (ii) multiple sets of term data, each set representibag 
attributes of a contract term, including a term code, a contract code, and term definitions for 
identifying transaction data sets apphcable to the contract term, and (iii) apluraUty of transaction 
data sets, each set being identified with a contracted transaction; 

one or more client stations for receiving transaction data sets, each data set relating to a 
purchasing transaction; and 

one or more data processing systems communicable with said one or more client stations 
and with said one or more data storage systems, said data processing systems being configured 
to store each of said transaction data sets in said one or more data storage systems; 

and 
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for each contract term, to compare at least a portion of said term data set with at 
least a portion of said transaction data sets so as to identify transaction data sets applicable to the 
contract term; and 

associating each of said identified transaction data sets with one or more of said 
entity data and tenn data to generate a collection of contract transaction data sets. 



5 3 . The system of claim 52, wherein the data processing system is configured to store 
each transaction data set in a common format. 



54. The system of claim 52, further comprising one or more data processing systems 
intercoupled with one or more of said data storage systems so as to be accessible with the 
contracted transaction data set, 

wherein said contracted transaction data sets are stored in said one or more data storage 
systems. 
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FIGURE 1: 
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FIGURE 2.A: 
METHOD OF GENERATING A CONTRACT 
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FIGURE 2.B: 
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FIGURE 2.C: > 
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FIGURE 3:. 
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FIGURE 4.A 
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FIGURE 5.A 
INPUT CONTRACT ENTITIES AND CONTACTS 
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FIGURE 5.B 
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FIGURE 4.B 
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FIGURE 6: 
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FIGURE 7. A: 
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FIGURE 7.B: 
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FIGURE 7.C: 
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FIGURE 8.B 
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FIGURE 8.C 
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FIGURE 8.D 
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FIGURE 8.E 

DEFINE CONTRACT AND PERFORMANCE TERMS 



DEFINE CRITERIA DISCOUNT PAYOUT 



ENTER MARKET(S) FOR PAYMENT 



ENTER SUPPLIER(S) FOR PAYMENT 



ENTER PRODUCT(S) FOR PAYMENT 

■ ♦ - 



ENTER CLASS(ES) FOR PAYMENT 



I 



STORE PAY- ON CRITERIA AS SQL 
STATEMENT IN TERM DEFINITION DATABASE 



J 



J 



J 



851 



853 



855 



857 



859 



J 



861 




YES 



SUBSTITUTE SHEET (RULE 26) 



wo 01/75745 PCT/USOl/10798 

19/46 



FIGURE 8.F 
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FIGURE 8.G 
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FIGURE 8.H 

DEFINE CONTRACT AND PERFORMANCE TERMS 



SELECT PAYOUT TIMING: POINT-OF-SALE OR END-OF-PERIOD 



885 



I 



SELECT PERFORMANCE REQUIREMENT: SHARE OF COUNT BY 
SUPPLIER. SHARE OF TOTAL SPEND, COUNT OF PRODUCT 



T 



SELECT DISCOUNT TYPE: PERCENT OF AMOUNT, FIXED PRICE, J" 
OR FLAT AMOUNT OFF 



887 



889 




SUBSTITUTE SHEET (RULE 26) 



wo 01/75745 



22/46 



PCT/USOl/10798 



FIGURE 8.1 
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FIGURE 9.A 
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FIGURE 9.B 
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FIGURE 9.C 
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FIGURE 1 0A 
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FIGURE 10.B; 
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FIGURE 11. A 
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FIGURE 11. B 
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FIGURE 12.A 
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FIGURE 12.B 
FORECAST CONTRACT PERFORMANCE 
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FIGURE 13 
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FIGURE 14.A 
AUDIT DISCOUNTED TRANSACTIONS 
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FIGURE 14.B 
AUDIT DISCOUNTED TRANSACTIONS 
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FIGURE 15A: 
MEASURE ACTUAL CONTRACT PERFORMANCE 
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FIGURE 1 SB: 
MEASURE ACTUAL CONTRACT PERFORMANCE 
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FIGURE 16: 
RECONCILE TERM PERFORMANCE 
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FIGURE 17: 
PAYOUT DISCOUNT 
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FIGURE 18: 
MANAGE SALES GOALS 



START ^ 



IDENTIFY SALES PERSON OR REGION FROM 
CONTACTS DATABASE 



MATCH TO CONTRACTS FROM 
TERM PERFORMANCE DATABASE 



RETRIEVE TERM PERFORMANCE RESULTS FROM 
TERM PERFORMANCE DATABASE 



1801 



1803 



1805 



RETRIEVE SALES GOALS FROM 
SALES GOAL DATABASE 



COMPUTE VARIANCE BETWEEN CONTRACT 
PERFORMANCE AND GOAL 



STORE RESULTS IN SALES GOAL DATABASE 



PRODUCE SALES 
PERFORMANCE REPORTS 



1807 



y 



1809 



y 



1811 



y 



1813 




END ^ 



SUBSTITUTE SHEET (RULE 26) 



wo 01/75745 



40/46 



PCT/USOl/10798 



FIGURE 19 
TRANSACTION DETAIL DATA SCREEN 
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FIGURE 20 
MARKET ANALYSIS SUMMARY SCREEN 
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FIGURE 21A 
DISCOUNT-ON REQUIREMENTS SCREEN 
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FIGURE 21 B 
MEASURE-ON REQUIREMENTS SCREEN 
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FIGURE 21C 
FINANCIAL REQUIREMENTS SCREEN 
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FIGURE 22: 
CONTRACT FORECAST SCREEN 
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FIGURE 23: 

ACTUAL CONTRACT PERFORMANCE SCREEN 
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